[Seaside] GOODS connection question
Sebastián Sastre
ssastre at seaswork.com.ar
Wed Jun 16 04:34:12 CEST 2004
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
>
More information about the Seaside
mailing list