I have noticed that any time I have to access a session property, it takes a long time compared to accessing any other property. There is also a problem stepping through a session object with the debugger. It won't step through anything that starts with "Session." I have to set a break point below it and Resume through the "Session."

If I understand how all this works correctly, there is a separate instance of the entire app for each session. Why then would I want to use "Session." properties (or methods) instead of "App." properties? All the documentation I have read says to make your database a property of the session. Is there something special about a database that requires it to be a session object while other properties can be app objects? Or should I not use app properties?

I have tried assigning properties to the app and have not noticed any problems, but I am reluctant to use them in a published app for fear of the database admonition.

If you set a property in the App class, it is accessible to every user that connects to your app and will be the same for every user connecting...if you set the property in the session...each user's setting will be individualized....

example...location to the app database would be the same for every user (app class)

If I understand how all this works correctly, there is a separate instance of the entire app for each session.

You misunderstand. There is a single instance of the app running on the server. Each user connects to that single instance. There is one app object. A new Session object is created for each connection.

The properties in app are global to all sessions. You shouldn't put a database connection in app because all your queries would run through that one pipe. And if any session closes the db, it is closed for everyone. Therefore, put the database object in the session.

One other thing to be aware of is that "Session" is a function, not a property. It has to do a bunch of work behind the scenes. So use local, temporary variables instead of access session.xxx over and over.

Let's see if I got this right. There is just one instance of the app and there is a separate instance of each web page for each session. The temporary variables are then properties of a webpage or container.

The app I am working on now has an smtp class for sending emails. That should probably also not be in the app as two calls to it at the same time could cause a problem. Is that correct?

How about modules. Are they global to each session or a separate instance for each session?

Putting simulanics' and timshare's comments together, I am getting the idea that it might be efficient to make the database an app object then open an instance of it in the session and make the connection. I was led to this while reading about using RealSQLDatabase in web apps where comments have said writes from different users don't cause problems because the app takes care of it. I am suggesting code like this for the app

I am wondering if this would have any advantage over creating a separate database object in each session. Specifically, does the app know about all the database connections and control writing to the db from different sessions without making the db an app object?

That won't work, the instance would still be shared between all sessions. You have one instance for each time you use the keyword "new".

As for the SMTP class, I would put that on App. It is impossible for two calls to happen at the same time, as only one line of code can execute at a time. There is no advantage to making one connection per session in that case.

The main reason you want one database connection per session is transactions. Since loop boundaries can trigger thread context switches, you want to be certain that all related queries are encapsulated together. Otherwise, you can find yourself in serious trouble.

Tim is absolutely correct about Session being a function though. It is an expensive function, as it has to map the current thread to a session object. It does this using dictionaries, but it still has to determine the current thread, and all that. So if you need to make even a few calls to Session in the same method, use a temporary variable. This is one of my favorite lines of code, because it's perfectly legal despite looking completely insane:

That won't work, the instance would still be shared between all sessions. You have one instance for each time you use the keyword "new".

As for the SMTP class, I would put that on App. It is impossible for two calls to happen at the same time, as only one line of code can execute at a time. There is no advantage to making one connection per session in that case.

The main reason you want one database connection per session is transactions. Since loop boundaries can trigger thread context switches, you want to be certain that all related queries are encapsulated together. Otherwise, you can find yourself in serious trouble.

Tim is absolutely correct about Session being a function though. It is an expensive function, as it has to map the current thread to a session object. It does this using dictionaries, but it still has to determine the current thread, and all that. So if you need to make even a few calls to Session in the same method, use a temporary variable. This is one of my favorite lines of code, because it's perfectly legal despite looking completely insane:

Dim Session As Session = Session

That simple addition can make a world of difference.

Sorry, re-reading this and had a couple of questions.

In ColdFusion, you defined the DB connection in the CF Administrator and done. Your code, when called, uses that connection. You can lock the app for brief moments when executing updates if needed. Or you can code a record lock if needed. But, it's one connection point to the DB.

With WE, you need to have a connection for each client? We have thousands of simultaneous users, this would result in thousands of connections to the DB? These connections are maintained? That seems very inefficient and an easy way to overload you DB server.

What about properties in Web Pages or Web Containers? Are they App wide (meaning server side) or or session (meaning client side) based?

They are not app wide. They are per session (server side - not client side).

Quote:

In ColdFusion, you defined the DB connection in the CF Administrator and done. Your code, when called, uses that connection. You can lock the app for brief moments when executing updates if needed. Or you can code a record lock if needed. But, it's one connection point to the DB.

With WE, you need to have a connection for each client? We have thousands of simultaneous users, this would result in thousands of connections to the DB? These connections are maintained? That seems very inefficient and an easy way to overload you DB server.

I seriously doubt CF is using a single database connection for all sessions. You set it up once, but it spawns a separate connection for each client. If you think about it, WE works the same way - set up the connection details once, get a separate connection for each session. I don't see much difference.

The database is optimized for multiple connections. A single, shared connection would become a major bottleneck.

Tim is absolutely correct about Session being a function though. It is an expensive function, as it has to map the current thread to a session object. It does this using dictionaries, but it still has to determine the current thread, and all that. So if you need to make even a few calls to Session in the same method, use a temporary variable. This is one of my favorite lines of code, because it's perfectly legal despite looking completely insane:

Dim Session As Session = Session

That simple addition can make a world of difference.

This is important information, and this is the first time I heard. It is stated in the documentation?

Tim is absolutely correct about Session being a function though. It is an expensive function, as it has to map the current thread to a session object. It does this using dictionaries, but it still has to determine the current thread, and all that. So if you need to make even a few calls to Session in the same method, use a temporary variable. This is one of my favorite lines of code, because it's perfectly legal despite looking completely insane:

Dim Session As Session = Session

That simple addition can make a world of difference.

So it would be profitable to put this line of code in all methods that contain at least two calls to the Session?

Tim is absolutely correct about Session being a function though. It is an expensive function, as it has to map the current thread to a session object. It does this using dictionaries, but it still has to determine the current thread, and all that. So if you need to make even a few calls to Session in the same method, use a temporary variable.

I can't seem to get worse then 2-3 microseconds when timing Session. As a matter of habit I store function results in local variables. But I don't consider Session to be expensive, and probably wouldn't comb through code trying to isolate Session calls.

Am I missing something? Is it dog slow on shared hosting or something?

Tim is absolutely correct about Session being a function though. It is an expensive function, as it has to map the current thread to a session object. It does this using dictionaries, but it still has to determine the current thread, and all that. So if you need to make even a few calls to Session in the same method, use a temporary variable.

I can't seem to get worse then 2-3 microseconds when timing Session. As a matter of habit I store function results in local variables. But I don't consider Session to be expensive, and probably wouldn't comb through code trying to isolate Session calls.

Am I missing something? Is it dog slow on shared hosting or something?

Agreed. I put properties in the Session all the time and have not noted any significant speed hits. I have a bunch of cgi apps that do this.

If it's using a dictionary you'd think it would be pretty fast. The hash table of a dictionary object is supposed to be very fast. It looks like Daniel has done some testing and 2-3 microseconds is typical, from what I know, of accessing objects through a dictionary lookup.

Thom, can you please answer us?This can have a great importance for our applications.

For example, I have a module ("Data") that contains all my database methods. Each method includes at least two calls to the session. One for operation ("session.db.sqlSelect ...") and one for the error checking ("if session.db.error.....") .

In my webPages, I often have transactions with ten or twenty database methods.