Re: JDBC session store, release date projections, etc
Dunlop, Aaron wrote: [...] First: We will need to cluster application servers in front of a central database. We want the ability to add and remove servers from that farm in real-time, without disturbing ongoing sessions. That either means storing sessions remotely in the central DB, or migrating sessions from one machine to another. We'd like to avoid being forced into using session-affinity for load balancing, since in our environment, that would likely result in significantly unbalanced loads. There is some effort going on to provide Clustering ability for TC4, currently you can use it for in memory replication of sessions, however this feature is considered highly experimental. So that probably means we need JDBC session store. Correct? And if so, what (in your opinions) is the current state of JDBC Session Store? (Also - am I correct that it's only available under Tomcat 4.0? Will it eventually also be available under the 3.x series?) When it comes to storing sessions you can use either FileStore or JDBCStore, I would say that both are considered medium rare. ..bip
Re: JDBC session store, release date projections, etc
On Thu, 24 May 2001, Dunlop, Aaron wrote: First: We will need to cluster application servers in front of a central database. We want the ability to add and remove servers from that farm in real-time, without disturbing ongoing sessions. That either means storing ... So that probably means we need JDBC session store. Correct? And if so, what (in your opinions) is the current state of JDBC Session Store? (Also - am I correct that it's only available under Tomcat 4.0? Will it eventually also be available under the 3.x series?) It shouldn't be difficult to port it to 3.x, but I don't think this is a priority. I also don't think such a thing should be included in 3.x - if anyone does the port, it should be released as a separate module. We are trying hard to keep 3.x to the essential level and move any non-essential features outside of the standard release. My personal opinion is that such code shouldn't even be part of the servlet container - but implmented as a user-space util. I know most people have a different opinion. If you want your data stored in a JDBC database - it's far better to do it yourself, and treat the tomcat session as a simple cache. You'll have far more flexibility, the code will run on any servlet container, you'll have access to a more powerfull API ( like transactions ). There is no way to insure consistency ( or acid) using only the session API - saving an object in the session and hoping the container will save it is far worse than using an API that will also tell you if the operation was successfully executed ( and no container can guarantee the save was successfull - there is no way to pass this information in the servlet api). Of course, I am probably wrong - since most people seem to believe the container can hide such a complex problem behind the simple session API. Costin
RE: JDBC-Session store
Jone Lin typed the following on 03:35 PM 3/28/2001 -0800 No, we're much earlier in the development cycle than that - we haven't implemented any distributed session support at all. The work we're doing on PersistentManager is groundwork for distributed sessions. This work is 90% finished, so after restructuring the relevant class hierarchy a bit and finishing PersistentManager, we'll be ready to tackle DistributedManager. What is schedule for these two nice managers? Tomcat 4.1, maybe? PersistentManager will be in the next beta, albeit in a slightly unfinished form: it swaps out idle sessions, but doesn't back up sessions. Whether DistributedManager makes it into 4.1 depends on the relative development pace of it vs. the whole Tomcat - i.e., if we finish it before the release, it'll go in. Sounds like there's a fair amount of interest, so hopefully we'll have plenty of hands to get it done. It might even make it into 4.0, since the final release has to wait on the 2.3/1.2 spec release. Kief
Re: JDBC-Session store
Bip Thelin typed the following on 10:46 AM 3/28/2001 -0800 I couldn't find anything about how to add the PersistenManager in server.xml or in the manuals, however, after backtracking the maillist I found a "patch" by Kief that seems to have been forgotten, I'll cat it to the end of this mail. Maybe it can find it's way into the server.xml after all. Excellent, I was wondering where that had gone. I'll commit it after the codefreeze is lifted.
Re: JDBC-Session store
Craig R. McClanahan typed the following on 07:05 PM 3/27/2001 -0800 Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? Yes, in fact I was just working on this last week, playing around with different ways of attacking this. Replacing dependencies on StandardManager, StandardSession with dependencies on the Manager and Session interfaces is relatively easy, with a few additions to the interfaces required. Another problem I've been tackling is the architecture of the Manager hierarchy. The problem is that there is code currently in StandardManager which is needed by (and currently, duplicated in) PersistentManager, which isn't good for maintenance. StandardManager implements the Lifecycle interface and functionality to expire sessions with a background thread. These are also used by PersistentManager, with the session management code being extended to handle swapping out idle sessions and similar tasks. Currently, StandardManager also has persistence code, which is used only to handle saving sessions on restarts. This code doesn't use the Store system. There are two approaches which seem like they would address this. One solution is to make StandardManager and PersistentManager subclasses of a common superclass with the functionality common to both. Another is to make PersistentManager a subclass of StandardManager. The first approach, making a hierarchy, appeals to me because it makes it easier to experiment with alternative session managers. DistributedManager would become a sibling to StandardManager and PersistentManager. This solution requires either moving the common functionality into the ManagerBase class, or creating an intermediary abstract class. The second approach allows the ManagerBase to remain a clean implementation of the Manager interface, although it extends the hierarchy an extra level. The second approach doesn't appeal to me, mainly because it seems likely to get a bit muddled over time. Either way, another issue I see is that StandardManager, as long as it supports persistence on restarts, is going to use a fair amount of the code from PersistentManager. This isn't necessarily a bad thing, it will keep PersistentManager fairly simple. But I would prefer to make it easy to develop a fully working Manager which doesn't include any persistence whatsoever: either StandardManager could have this (requiring users who want restart persistence to use PersistentManager), or there could be a separate SimpleManager. The first of the two solutions: making StandardManager and PersistentManager siblings rather than one a subclass of the other, seems likely to offer cleaner support for a StandardManager without persistence and/or a SimpleManager. Once the beta is tagged (this weekend?) I can start committing some work on this. Kief
Re: JDBC-Session store
Kief Morris wrote: Excellent! Let us know if you need any help. I will, BTW how is the work on distributed sessions coming along? Is it possible to distribute sessions over x number of machines and that if one goes down you could go to the other and happily continue your session? ..bip
Re: JDBC-Session store
Bip Thelin typed the following on 05:07 PM 3/27/2001 -0800 Kief Morris wrote: Excellent! Let us know if you need any help. I will, BTW how is the work on distributed sessions coming along? Is it possible to distribute sessions over x number of machines and that if one goes down you could go to the other and happily continue your session? No, we're much earlier in the development cycle than that - we haven't implemented any distributed session support at all. The work we're doing on PersistentManager is groundwork for distributed sessions. This work is 90% finished, so after restructuring the relevant class hierarchy a bit and finishing PersistentManager, we'll be ready to tackle DistributedManager. The session management system consists of implementations of the Manager, Session, and Store interfaces found in the root org.apache.catalina package. When we finish with it, we should have three implementations of Manager: StandardManager, PersistentManager, and DistributedManager. Any Store implementations should, in theory, be usable by either of the second two. So your JDBCStore class, if it works with PersistentManager, should also work with DistributedManager. The only difference is how the Store is used by the Manager: PersistentManager only stores the sessions of one JVM, while DistributedManager will store them for multiple JVMs. In reality, I suspect that DistributedManager will require changes to the current Store interface, so if you implement JDBCManager now and get it working with PersistentManager, it may have to be updated as we work on DistributedManager. If you want to help with DistributedManager, doing JDBCStore might be a good first step for you to get your head into the code. One issue I haven't figured out yet is how to configure Catalina to use different Store implementations - PersistentManager currently has FileStore hard-coded. If you want to dig into that it would be a bonus. Catalina's configuration system is really slick. There should be some messages of mine from a few months ago in the archive for this list where I puzzled over some of the particular issues of implementing DistributedManager which may or may not be worth looking over. Kief
RE: JDBC-Session store
-Original Message- Bip Thelin typed the following on 05:07 PM 3/27/2001 -0800 Kief Morris wrote: Excellent! Let us know if you need any help. I will, BTW how is the work on distributed sessions coming along? Is it possible to distribute sessions over x number of machines and that if one goes down you could go to the other and happily continue your session? No, we're much earlier in the development cycle than that - we haven't implemented any distributed session support at all. The work we're doing on PersistentManager is groundwork for distributed sessions. This work is 90% finished, so after restructuring the relevant class hierarchy a bit and finishing PersistentManager, we'll be ready to tackle DistributedManager. What is schedule for these two nice managers? Tomcat 4.1, maybe?
Re: JDBC-Session store
"Craig R. McClanahan" wrote: [...] Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? I couldn't find anything about how to add the PersistenManager in server.xml or in the manuals, however, after backtracking the maillist I found a "patch" by Kief that seems to have been forgotten, I'll cat it to the end of this mail. Maybe it can find it's way into the server.xml after all. Cheers, Bip --[ server.xml patch from Kief Morris ] --- server.xml.orig Sat Dec 16 20:03:29 2000 +++ server.xml Fri Jan 12 22:01:04 2001 @@ -179,6 +179,53 @@ Ejb name="ejb/EmplRecord" type="Entity" home="com.wombat.empl.EmployeeRecordHome" remote="com.wombat.empl.EmployeeRecord"/ +!-- + PersistentManager + Uncomment the section below to test Persistent Sessions. + + saveOnRestart: If true, all active sessions will be saved + to the Store when Catalina is shutdown, regardless of + other settings. All Sessions found in the Store will +be + loaded on startup. Sessions past their expiration are + ignored in both cases. + maxActiveSessions: If 0 or greater, having too many active + sessions will result in some being swapped out. +minIdleSwap + limits this. -1 means unlimited sessions are allowed. + 0 means sessions will almost always be swapped out +after + use - this will be noticeably slow for your users. + minIdleSwap: Sessions must be idle for at least this long + (in seconds) before they will be swapped out due to + maxActiveSessions. This avoids thrashing when the site +is + highly active. -1 or 0 means there is no minimum - +sessions + can be swapped out at any time. + maxIdleSwap: Sessions will be swapped out if idle for this + long (in seconds). If minIdleSwap is higher, then it +will + override this. This isn't exact: it is checked +periodically. + -1 means sessions won't be swapped out for this reason, + although they may be swapped out for maxActiveSessions. + If set to = 0, guarantees that all sessions found in +the + Store will be loaded on startup. + maxIdleBackup: Sessions will be backed up (saved to the Store, + but left in active memory) if idle for this long (in +seconds), + and all sessions found in the Store will be loaded on +startup. + If set to -1 sessions will not be backed up, 0 means +they + should be backed up shortly after being used. + + To clear sessions from the Store, set maxActiveSessions, +maxIdleSwap, + and minIdleBackup all to -1, saveOnRestart to false, then +restart + Catalina. + -- + !-- + Manager className="org.apache.catalina.session.PersistentManager" + debug="0" + saveOnRestart="true" + maxActiveSessions="-1" + minIdleSwap="-1" + maxIdleSwap="-1" + maxIdleBackup="-1" + Store className="org.apache.catalina.session.FileStore"/ + /Manager + -- Environment name="maxExemptions" type="java.lang.Integer" value="15"/ Parameter name="context.param.name" value="context.param.value"
Re: JDBC-Session store
Grr, seems my message got stuck somewhere so I'll resend it. "Craig R. McClanahan" wrote: [...] Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? I couldn't find anything about how to add the PersistenManager in server.xml or in the manuals, however, after backtracking the maillist I found a "patch" by Kief that seems to have been forgotten, I'll cat it to the end of this mail. Maybe it can find it's way into the server.xml after all. Cheers, Bip --[ server.xml patch from Kief Morris ] --- server.xml.orig Sat Dec 16 20:03:29 2000 +++ server.xml Fri Jan 12 22:01:04 2001 @@ -179,6 +179,53 @@ Ejb name="ejb/EmplRecord" type="Entity" home="com.wombat.empl.EmployeeRecordHome" remote="com.wombat.empl.EmployeeRecord"/ +!-- + PersistentManager + Uncomment the section below to test Persistent Sessions. + + saveOnRestart: If true, all active sessions will be saved + to the Store when Catalina is shutdown, regardless of + other settings. All Sessions found in the Store will +be + loaded on startup. Sessions past their expiration are + ignored in both cases. + maxActiveSessions: If 0 or greater, having too many active + sessions will result in some being swapped out. +minIdleSwap + limits this. -1 means unlimited sessions are allowed. + 0 means sessions will almost always be swapped out +after + use - this will be noticeably slow for your users. + minIdleSwap: Sessions must be idle for at least this long + (in seconds) before they will be swapped out due to + maxActiveSessions. This avoids thrashing when the site +is + highly active. -1 or 0 means there is no minimum - +sessions + can be swapped out at any time. + maxIdleSwap: Sessions will be swapped out if idle for this + long (in seconds). If minIdleSwap is higher, then it +will + override this. This isn't exact: it is checked +periodically. + -1 means sessions won't be swapped out for this reason, + although they may be swapped out for maxActiveSessions. + If set to = 0, guarantees that all sessions found in +the + Store will be loaded on startup. + maxIdleBackup: Sessions will be backed up (saved to the Store, + but left in active memory) if idle for this long (in +seconds), + and all sessions found in the Store will be loaded on +startup. + If set to -1 sessions will not be backed up, 0 means +they + should be backed up shortly after being used. + + To clear sessions from the Store, set maxActiveSessions, +maxIdleSwap, + and minIdleBackup all to -1, saveOnRestart to false, then +restart + Catalina. + -- + !-- + Manager className="org.apache.catalina.session.PersistentManager" + debug="0" + saveOnRestart="true" + maxActiveSessions="-1" + minIdleSwap="-1" + maxIdleSwap="-1" + maxIdleBackup="-1" + Store className="org.apache.catalina.session.FileStore"/ + /Manager + -- Environment name="maxExemptions" type="java.lang.Integer" value="15"/ Parameter name="context.param.name" value="context.param.value"
RE: JDBC-Session store
Blob is a bad idea. Serialize the objects and store them as varchar. We implemented a home grown session store and the varchar route works lot better. I believe IBM's WebSphere session store also uses varchars. Krishna -Original Message- From: Bip Thelin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 2:13 AM To: [EMAIL PROTECTED] Subject: JDBC-Session store I've been looking at the FileStore implementation and you(Kief/Craig) basically store a java object in the textfile, using the same approach with a DB usually(?!) involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want to store the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of reluctant to save objects in to a RDBMS and sort or "overriding" the native formats. Have anyone got any ideas on how to solve this in a good way? Preferably so it would work with JDBC 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go ahead and implement it as either a blob or a STRUCT whichever works out best. Thanks, Bip
Re: JDBC-Session store
In the Java world, varchar should support UNICODE characters, not 8-bit bytes. Yes, I know some data bases do not store UNICODE, but some (Oracle, InstantDB etc) do. The other problem with character, is character encoding, when/if the encoding of the application does not match the native character encoding of the table, a translation is performed, and the results are not always reversible. The correct type used to store serialized data is byte, or varbyte, or even blob. Remember, Java characters are unsigned sixteen bit numbers not eight bit data elements (called char by 'C', 'C++' and many databases). - Original Message - From: Krishna R. Baddam [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 28, 2001 7:25 PM Subject: RE: JDBC-Session store Blob is a bad idea. Serialize the objects and store them as varchar. We implemented a home grown session store and the varchar route works lot better. I believe IBM's WebSphere session store also uses varchars. Krishna -Original Message- From: Bip Thelin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 2:13 AM To: [EMAIL PROTECTED] Subject: JDBC-Session store I've been looking at the FileStore implementation and you(Kief/Craig) basically store a java object in the textfile, using the same approach with a DB usually(?!) involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want to store the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of reluctant to save objects in to a RDBMS and sort or "overriding" the native formats. Have anyone got any ideas on how to solve this in a good way? Preferably so it would work with JDBC 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go ahead and implement it as either a blob or a STRUCT whichever works out best. Thanks, Bip
Re: JDBC-Session store
On Tue, 27 Mar 2001, Kief Morris wrote: Bip Thelin typed the following on 01:56 PM 3/26/2001 -0800 According to the STATUS.html(which doesn't seem to be up to date) no one seems to have volunteered for the JDBC-Session store. If that is truly the case I would like to volunteer for that part. Excellent! Let us know if you need any help. Kief Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? Craig
JDBC-Session store
According to the STATUS.html(which doesn't seem to be up to date) no one seems to have volunteered for the JDBC-Session store. If that is truly the case I would like to volunteer for that part. Thanks, Bip
Re: JDBC-Session store
On Mon, 26 Mar 2001, Bip Thelin wrote: According to the STATUS.html(which doesn't seem to be up to date) no one seems to have volunteered for the JDBC-Session store. If that is truly the case I would like to volunteer for that part. Thanks, Bip That is the case currently, so I have added you to the list. Thanks for volunteering! Earlier, there was some discussion on refactoring the Manager/Session/Store family of interfaces (and corresponding interface classes) a little bit in the light of Kief's experience in adding PersistentManager. If you see things here that you think could be improved, don't hesitate to suggest them. Craig
