[Seaside] GOODS connection question

[Marco Paga]

Just as a sidekick:
"GOODS is a fully distributed database. The database consists of a number of 
storages,[...]. The client can work with an arbitrary number of databases at 
any time.[...]  The location of an object within the database is mostly 
transparent for clients [...]"
If you think that your single goods server is to slow you can scale up the 
third tier in the hope of getting the performance problem out of it.
Perhaps you need to find a way to scale up the seaside tier in any way. 
Perhaps there is any possibility with a load balancer, like apache with 
intelligent session names.



Am Mittwoch, 16. Juni 2004 04:34 schrieb 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
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside