[Seaside] GOODS connection question

[John R. Pierce]

> Avi wrote:
 
> Well, it comes down to transactional concurrency vs. (for lack of a 
> better term) re-entrant concurrency.  If you have 50 concurrent 
> sessions using the same connection and the same cache, suddenly you 
> have to worry about what happens if two users try to interact with the 
> same object from the database at the same time.
 
We are using a GOODS database to manage our Seaside application data and
have witnessed first hand what Avi was talking about – except we experience real
concurrency problems at 2 users (not 50).  We did some testing and it is as
Avi says – you pretty much shouldn’t share the same GOODS cache between
Sessions unless you perform some sort of locking (yuck!).
 
> If you have one connection and one cache per session, you only have to 
> deal with concurrency at well defined points, and in well-defined ways: 
> when each session commits.  Yes, you use more memory, but the code is 
> much, much easier to write.
 
Yep, this is the solution we settled on – and it works quite well.  Actually
our application just opens a connection and gets objects whenever it needs them
so we didn’t even put a cache of objects in the session.  I suspect if you design
your GOODS database properly this will perform just fine (e.g. don’t fetch 10,000
objects all the time just to get to the one you want).
 
If you put the cache in the session, I wonder when WASession get collected? 
I wouldn’t want the cache to live too long (my only concern).
 
> One compromise in some situations would be to have one database that 
> was read-only or rarely written to, that had a connection shared among 
> all sessions, and another database with the more volatile data that had 
> a connection for each.
 
We just shared one read-only connection to the same GOODS database that was held
onto by the application for all sessions to use when it came to reporting.  
This seemed to provide a nice speed boost for our application’s reporting
function.
Before using the connection we just called refresh to get the latest version of
objects
and this was much faster than starting with no cache.  Just make sure not to use
this connection for anything but reading.
 
Regards,
 
John