Having an in-memory database limits you to one JVM. You can just as easily use a real db for this task.
We have solved this problem a long time ago using the database session approach. However, based on experience with our highly concurrent system, you should store as little as possible in this table. We store a randomly generated "session" token that gets mirrored in the server and client cookies. There is also a small amount of misc data like user id and server, etc. We use this approach for handling load balances, single sign-ons, and server crashes. We have had very good results. Of course, this is not as performant as an in memory session and newer clustering technologies are under evaluation at my company, but the db approach is tried and true, and can be made very fast. It will come down to the hardware you can afford. Note: if your system will be highly concurrent, you must absolutely ensure that indexes are properly setup on your table and that queries against this table are managed. The last thing you want is to have somebody foolishly join to this table in a multi-join query and lock it. We've also had this happen when we were working the kinks out. Be careful. There's nothing like a blocking query to make your highly concurrent system grind to a halt. This problem is not always obvious, especially when the details are masked from your developers by an ORM. On 11/20/05, Richard Clark <[EMAIL PROTECTED]> wrote: > > I've done something similar to this in Tapestry 3. > > Let's say you have two apps: Catalog and Checkout, and that the user > is always sent to Catalog first. Catalog would then assign a "working > user ID", and dump its state to the database under that ID. When it's > time to go to the Checkout, use the External service to construct a > link with the working user ID and a full path to the Checkout > application. You can then make that a clickable link or redirect to > it -- the single redirection would contain the one think you need > (the working user ID) to pull info up from the database. > > If the apps need to do more concurrent communication, Java RMI is a > possibility, but I suspect you don't need quite that much back-and- > forth. > > ...Richard > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
