[Seaside] GOODS connection question

[Sebastián Sastre]

People lets buy DIMMS !!!

	he he he

	No, I'm serious. The solution you describe is by far, cheaper in
time and probably $$

	thanks again for clarifying our minds,

Sebastián Sastre
ssastre at seaswork.com.ar
www.seaswork.com.ar


> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Avi Bryant
> Enviado el: Martes, 15 de Junio de 2004 23:24
> Para: The Squeak Enterprise Aubergines Server - general discussion.
> Asunto: Re: [Seaside] GOODS connection question
> 
> 
> 
> 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
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>