[Seaside] GOODS connection question

[Sebastián Sastre]

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Marco Paga
> Enviado el: Miércoles, 16 de Junio de 2004 14:32
> Para: The Squeak Enterprise Aubergines Server - general discussion.
> Asunto: Re: [Seaside] GOODS connection question
> 
> 
> 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.
Marco,

 I'm interested on making the load balance because we are buiding a
system that will begin with 400 users but the it will scale for arround
14K. 

	If you have any recomended lecture I'll appreciate it,

	regards,

Sebastián Sastre
ssastre at seaswork.com.ar
www.seaswork.com.ar
> 
> 
> 
> 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
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>