Real Software Forums

The forum for Real Studio and other Real Software products.
[ REAL Software Website | Board Index ]
It is currently Sat Dec 16, 2017 11:52 am
xojo

All times are UTC - 5 hours




Post new topic Reply to topic  [ 15 posts ] 
Author Message
 Post subject: When to use app properties vs session properties
PostPosted: Thu Apr 11, 2013 6:48 pm 
Offline

Joined: Fri Jun 02, 2006 1:43 pm
Posts: 209
Location: Santa Ynez, CA
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Thu Apr 11, 2013 6:59 pm 
Offline
User avatar

Joined: Sun Aug 12, 2007 10:10 am
Posts: 1086
Location: Boiling Springs, SC
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...

_________________
Matthew A. Combatti
Real Studio 2012 r1.2

Visit Xojo Developer's Spot!
Systems I Use:
Windows XP/Windows Vista/Windows Server 2008 r2/Windows 7/Windows 8
Mac OSX 10.5/Mac OSX 10.6/Mac OSX Server/Ubuntu/Debian/Suse/Red Hat/
Windows Server 2011/CentOS 5.4 /ReactOS/SimOS

~All Xojo Compatible~


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Thu Apr 11, 2013 7:21 pm 
Offline

Joined: Fri Jan 06, 2006 3:21 pm
Posts: 12388
Location: Portland, OR USA
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


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Fri Apr 12, 2013 6:56 pm 
Offline

Joined: Fri Jun 02, 2006 1:43 pm
Posts: 209
Location: Santa Ynez, CA
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Sat Apr 13, 2013 1:21 am 
Offline

Joined: Fri Jan 06, 2006 3:21 pm
Posts: 12388
Location: Portland, OR USA
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Sat Apr 13, 2013 11:32 am 
Offline

Joined: Fri Jun 02, 2006 1:43 pm
Posts: 209
Location: Santa Ynez, CA
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Sat Apr 13, 2013 12:07 pm 
Offline
Site Admin
User avatar

Joined: Tue May 06, 2008 1:07 pm
Posts: 1464
Location: NotEvenOnTheMap, CT
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.

_________________
Thom McGrath - @tekcor
Web Framework Architect, Real Software, Inc.


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Fri May 10, 2013 11:19 am 
Offline

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!


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Fri May 10, 2013 11:56 am 
Offline

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!


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Fri May 10, 2013 12:23 pm 
Offline

Joined: Fri Jan 06, 2006 3:21 pm
Posts: 12388
Location: Portland, OR USA
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Sat May 11, 2013 11:52 pm 
Offline

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?


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Sun May 12, 2013 12:32 am 
Offline

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?


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Sun May 12, 2013 12:33 am 
Offline

Joined: Wed Mar 22, 2006 11:15 am
Posts: 712
Location: Southern California
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?

_________________
Daniel L. Taylor
Custom Controls for Real Studio WE!
Visit: http://www.webcustomcontrols.com/


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Sun May 12, 2013 12:43 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 11:48 am
Posts: 3554
Location: Lenexa, KS
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.

_________________
Bob K.

A blog about being a Real Studio/Xojo developer at http://www.bkeeneybriefs.com


Top
 Profile  
Reply with quote  
 Post subject: Re: When to use app properties vs session properties
PostPosted: Tue May 21, 2013 4:23 am 
Offline

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 5 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group