[Seaside] GOODS connection question

Julian Fitzell julian at beta4.com
Wed Jun 16 21:50:14 CEST 2004


Have a look at some of my postings in the last few weeks... I described 
how we use apache load balancing with our seaside app at work.

Avi and I have been talking about writing up some real documentation on 
this, but it hasn't happened so far.

Julian

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


More information about the Seaside mailing list