we have an application which is running for multiple countries and may users can be at same time, This piece of code is showing an error on The page

cflock timeout="10" scope="Session" type="Exclusive">
		<CFPARAM NAME="Session.loginid" DEFAULT=0>
 	</cflock>

i check some tutorials and getting a very vague answer, some say do not use it, some say names should be used instead of scope, so not sure ho can i fix it

What error is it showing?

FYI, you can set session defaults in the Application.cfc onSessionStart() and you don't have to worry about locking. in onSessionStart(), since it's thread safe.

That code specifically is unlikely to be the cause of the error (although as others have said... time and time again... what's the error). It's require the app to have so many simultaneous requests that it takes so long to process all the

<cfparam>

calls that it can't get through them all in 10sec. Which is... unlikely. I don't think you need that lock there btw... no race condition to be had in any meaningful way. However as per my advice to someone a few weeks back... I'd not be writing to the session scope directly at all in my application code... I'd have it in a SessionAdapter or something. Probs not something that can be done for this specific issue though. So anyway... same old gig... explain yer question better, post errors, show the reading you've done, what troubleshooting you've tried etc.

so are u saying no need to cflock

No need to lock if it's in onSessionStart(), otherwise you will still need to lock when setting it.

TBH I think if one is just defaulting the value, there is no need to lock it. It's a single statement, and under the hood session stuff is synchronised anyhow. One used to have to lock all shared-scope access because the scope implementations were a) flaky; b) not synchronised, but that was back before CF was ported to Java. That said, I 100% agree that all initialisation / defaulting of session variables ought to be in

onSessionStart

as a matter of design anyhow (obvs no help to Gavy here). Gavy you need to bear in mind that where you are seeing the error is not necessarily what's causing the error. If you have

lock scope="session" type="exclusive" timeout="30" {
    sleep(29000)
}

Then you'll get your timeout error in the code you mentioned, but it's caused by the long-running code above, which will keep the session scope locked for 29sec.

and then i can use errorontimeout to silently kill it , because it keeps handing

@gsr What other part of the Application.cfm is touching the session scope, such that it can't create a lock without timing out? Could you post some code (maybe everything above and including the cflock section you showed on your initial post)?

The Application.cfm is a real pain now, even if i am implementing a new change, i have t think backwards, as an example trying to use the session timeout popup to let user know what is happening

It's pretty easy to convert from Application.cfm to Application.cfc.

@Adam Cameron that answer is last resort because website is too big and it needs tons of approval before we actually do that I wonder i see the session check is in header file so I think I can use javascript to check the session My only concern is to backup the session and then restore once the user clicks to continue the session I have the functions for that but I am just but lost how to call it because in application cfc file I can do that in method

I wonder i see the session check is in header file so I think I can use javascript to check the session

I recommend you don't start thinking about the solution to an issue until you identify the problem. Also: I can't see how JS is going to solve an issue with your CFML sessions.

Application.CFC, Cfinclude = allthecrapIhadinApplication.CFM now, daily, weekly, or when you have time start flagging your code where it should actually go in the Application.CFC. Is it an application variable, scope variable, session variable, or user-defined value that should be part of some template include? There is nothing wrong with using the Application.CFM, as it was great at just mushing all the crap together and it "just worked". However, knowing how the Application.CFC works and being able to slowly move your application code to the proper segments of the engine will only help you in the end maintain better code and give you more time to do something else.

@Adam Cameron I understand but your words are sometimes very bitter It’s not my choice to have managerial decisions but I can purpose that solution As far as the session restore and backup is concerned I am better be going with javascript using local storage and Ajax calls

There is nothing to force. You just state, if you want to pay more for inefficient code, which in turn requires you to spend a long time making improvements and spend more money on bigger servers for less throughput, leave it as is. If you want more efficent code, then they need to allow you a dev environment and at least a few hours a week to explore moving the code base from the application.cfm to application.cfc for the proposed purposes of efficiency, better ROI, and proposed changes in the CFML roadmap.

Ok I can check with them and see if that goes well

Not even that, @Evil Ware "if you want this issue fix, this is the fix. That's how we're fixing this". You're the dev doing the work, it's your call. Not your manager; they should not be fussing about implementation detail.

I give people the benefit of the doubt on this. He may be a young programmer or someone who was a sys admin or is a sys admin also wearing many hats who hasn't learned to set expectations. I have seen this a lot from new consultants and those new to the IT field.

@Evil Ware i see my Application.cfm and i see there are lot of unscoped variables, like this is written as: <cfset sDSN="something"> and application.cfc works best with the methods it defined, i do not want to go ahead, but i can pu these things in my onRequest and still saying its a big big change and project is too big to hndle from every end point

That is normal in the pre-2009 ish way of how Coldfusion was written. It just works. When migrating to an Application.CFC, you first need to understand all the various parts of how your application should work. It's why, as part of a migration to CFC, it could take some time, and that is okay. There is no "wrong way" to create an application.