When to use app properties vs session properties

dgdavidge · **Posted:** Thu Apr 11, 2013 6:48 pm

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.

simulanics · **Posted:** Thu Apr 11, 2013 6:59 pm

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)

username, password, identifying information is individualized (session class)

remember that debuggging will naturally be slower than the compiled build release...

timhare · **Posted:** Thu Apr 11, 2013 7:21 pm

dgdavidge wrote:

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.

dim db as database = session.db
db.xxx
db.yyy
etc

dgdavidge · **Posted:** Fri Apr 12, 2013 6:56 pm

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?

timhare · **Posted:** Sat Apr 13, 2013 1:21 am

Modules are always global, not in the sense of scope rules, but in that they are project-level so they are shared by whoever has access to them.

I would put the smtp object in the session - or the web page, even.

dgdavidge · **Posted:** Sat Apr 13, 2013 11:32 am

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

dim db as new RealSQLDatabase
db.databasefile = GetFolderItem(....)
db. multiuser = true

and this in the session

dim myDB as RealSQLDatabase = app.db
myDB.connect

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?

Thom McGrath · **Posted:** Sat Apr 13, 2013 12:07 pm

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.

GSMadMan · **Joined:** Tue Jul 10, 2007 12:16 pm **Posts:** 3

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

An example would be setting the clientTIme to a property in a web page or web container. Is that affecting the entire app or just the client like a hidden field?

I'm used to using Session variables for user specific info (coming from ColdFusion world), just trying to get my head wrapped around the differences.

Thanks!

GSMadMan · **Joined:** Tue Jul 10, 2007 12:16 pm **Posts:** 3

Thom McGrath wrote:

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.

Again, just trying to get my head wrapped around the differences.

Thanks!

timhare · **Posted:** Fri May 10, 2013 12:23 pm

Quote:

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.

paxdo · **Joined:** Fri Oct 28, 2011 3:42 pm **Posts:** 23

Thom McGrath wrote:

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?

paxdo · **Joined:** Fri Oct 28, 2011 3:42 pm **Posts:** 23

Thom McGrath wrote:

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?

taylor-design · **Posted:** Sun May 12, 2013 12:33 am

Thom McGrath wrote:

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?

Bob Keeney · **Posted:** Sun May 12, 2013 12:43 pm

taylor-design wrote:

Thom McGrath wrote:

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.

I think this is a red herring.

paxdo · **Joined:** Fri Oct 28, 2011 3:42 pm **Posts:** 23

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.

For example:

data.onTransaction
data.method1
data.method2
data.method10
data.offTransaction

In each of these methods, so there are at least two calls for the session ("session.db.sqlExecute/Select..." and "if session.db.error....").

The transaction (which must of course be extremely fast) therefore contains many calls to the session. Is that the transaction will be significantly slower?

From what you say, is that we should do:

Dim dB As Session = Session.db
data.onTransaction(db)
data.method1(db)
data.method2(db)
data.method10(db)
data.offTransaction(db)

with the database as a parameter of each method so that there is only one call in the session?

Thank you,

Olivier

	Real Software Forums The forum for Real Studio and other Real Software products.
[ REAL Software Website \| Board Index ]

Real Software Forums

When to use app properties vs session properties