Changes for page Development-WO Session

Summary

• Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-Programming__WebObjects-Web Applications-Development-WO Session
	1	+Web Applications-Development-WO Session

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.qdolan
	1	+XWiki.probert

Content

...	...	@@ -1,8 +1,8 @@
1		-== Overview ==
	1	+== Overview ==
2	2
3	3	A WOSession provides the encapsulation of all the state that is associated with a user's use of your application. Each WebObjects application has its own subclass of WOSession, which is a significant difference between session tracking in WebObjects and J2EE. In J2EE, HttpSession is not subclassed, and all state is stored as attributes in HttpSession's Map. In WebObjects, sessions are much richer, providing the ability to take advantage of all the benefits of being a full-blown class (typed fields, methods, etc). WOSessions have a timeout time, which by default is configured in the WOApplication configuration. This timeout time determines how long the server will keep the session alive without any active requests. When the session times out, it will be garbage collected.
4	4
5		-== Accessing the Session ==
	5	+== Accessing the Session ==
6	6
7	7	{{code}}
8	8
...	...	@@ -19,7 +19,7 @@
19	19
20	20	**Just one more word of caution do not set the session as a class variable of WOComponent or WODirectAction, this would create a loop and prevent the garbage collection of old sessions.**
21	21
22		-//Is the above really true? In a WO5 pure-Java application, circular references like this might create more work for the garbage collector, but shouldn't prevent anything from getting garbage collected. The Java garbage collector is supposed to handle circular references just fine. ~-~- JonathanRochkind//
	22	+//Is the above really true? In a WO5 pure-Java application, circular references like this might create more work for the garbage collector, but shouldn't prevent anything from getting garbage collected. The Java garbage collector is supposed to handle circular references just fine. - JonathanRochkind//
23	23
24	24	If you like to simplify your code just insert the following method in your component (this will save you some typing):
25	25
...	...	@@ -31,13 +31,13 @@
31	31
32	32	{{/code}}
33	33
34		-We always begin our projects with a WOComponent subclass that we use as a superclass for all the rest of our components. We include this method as well as a few other useful utility methods. --- JoshuaMarker--
	34	+We always begin our projects with a WOComponent subclass that we use as a superclass for all the rest of our components. We include this method as well as a few other useful utility methods. -- JoshuaMarker--
35	35
36		-As I recall the warnings about storing references to Session were specific to inner classes of Session. Storing references to Session inside another component is perfectly ok, although an accessor method is better. ~-~- BrianMarquis
	36	+As I recall the warnings about storing references to Session were specific to inner classes of Session. Storing references to Session inside another component is perfectly ok, although an accessor method is better. - BrianMarquis
37	37
38		-//I still think even this is not a problem in WO5, although it probably is in WO4.5. JRE 1.3.1 is supposed to garbage collect circular references just fine, whether involving an inner class or not. But maybe the JRE doesn't do what it's supposed to? ~-~- JonathanRochkind//
	38	+//I still think even this is not a problem in WO5, although it probably is in WO4.5. JRE 1.3.1 is supposed to garbage collect circular references just fine, whether involving an inner class or not. But maybe the JRE doesn't do what it's supposed to? - JonathanRochkind//
39	39
40		-== Session Tracking ==
	40	+== Session Tracking ==
41	41
42	42	The first time a session is requested for a request, WebObjects ensures that all subsequent requests from the same user will use the same WOSession instance. WebObjects achieves this session tracking with one of two techniques: URL rewriting, cookies, or query strings.
43	43
...	...	@@ -47,7 +47,7 @@
47	47
48	48	Lastly, you can pass a query string attribute named "wosid" that contains the session ID. This is often used when calling DirectActions that need access to the user's session.
49	49
50		-== Performance Implications ==
	50	+== Performance Implications ==
51	51
52	52	Session creation and persistence must be carefully monitored in large deployments due to the memory usage required to keep the session alive. It is generally recommended to minimize session creation whenever possible. When using "normal" WebObjects techniques, this can be difficult. The default behavior of WOHyperlink, for instance, when calling an action on your WOComponents is to cause sessions to be generated. The typical method for avoiding session creation is to implement your application using DirectActions. DirectActions do not require a page cache to be created for page state preservation, and thus can be used in a completely stateless way. The downside of using only DirectActions is that you lose the benefits of a more stateful approach. For instance, when using DirectActions only, you will find that you have to manually wire up your state objects by interpreting query string variables.
53	53
...	...	@@ -55,11 +55,11 @@
55	55
56	56	Adjusting your session timeout can have a large impact on performance. The longer a session timeout is, the longer the session will consume memory. Under heavy load, "dead" sessions can build up, so the timeout time should be tuned to be as low as possible without negatively affecting your user's experience with your application.
57	57
58		-== Hanging Sessions ==
	58	+== Hanging Sessions ==
59	59
60	60	There are certain cases in WebObjects where thrown exceptions can cause a session to not be checked back into the WOSessionStore, which will deadlock the session. One of the more common causes of this is an exception thrown from a DirectAction that uses a session. If you use Project Wonder's ERXApplication, ERXSession, etc, it provides a prevention mechanism for this problem. However, if you are using a default WebObjects installation without Project Wonder, you will need to deal with this problem yourself. You should not let your DirectActions throw an exception in this case.
61	61
62		-== Checking for Existing Session ==
	62	+== Checking for Existing Session ==
63	63
64	64	If you are in a DirectAction method when trying to do this, check the following WOAction method (WOAction is WODirectAction's superclass):
65	65
...	...	@@ -83,5 +83,3 @@
83	83	{{/code}}
84	84
85	85	Returns true if a session exists for the receiving context, false otherwise.
86		-
87		-Category:WebObjects