[Seaside] GOODS connection question

[Avi Bryant]

On Jun 15, 2004, at 6:38 PM, Sebastián Sastre wrote:

> Sorry but I don't see that pattern as a good one. (perhaps I'm missing
> something)
> In fact I'm thinking about having 50 simultaneous users.
> You'll have 50 db connections with 50 caches?

Yes.

> Why the 50 users cannot share just one connection with one cache and
> actively refresh it every time they expressely need to? Wich will be 
> the
> disvantage of having the db in a singleton that restarts with the image
> for example?

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.  You'd have to start 
putting locks *everywhere*, and you'd have to think hard about the 
semantics of concurrent edits.  Because of all the locking, it would 
probably be slow in unpredictable ways, and you would spend all of your 
time debugging deadlocks and race conditions.  Not fun.
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.
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.  It *may* even be possible to work things so 
that those two databases can cleanly reference each other, but I'd have 
to look closer at the distributed database model GOODS uses to be sure.

Avi