cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Obtaining DataContext in ZK
Date Wed, 23 May 2007 12:50:57 GMT
A note on DC thread-safety. With a few bug fixes that came out in  
2.0.3, DC is fully tread-safe in a read-only situation. In a read/ 
write situation DC is still technically thread-safe, but in practice  
at least two types of race conditions can happen:

* Two or more threads updating the same DataObject (i.e. DataObjects  
are not thread-safe)
* Two or more threads issuing "commit" or "rollback"

BTW, I like "one DC per session, one child DC per request" approach  
to solving the problem, but I am yet to try this in a heavily loaded  
read/write app.


P.S. Should we keep CAY-791 around as a bug, i.e. is there a  
framework-level solution to that, other than better documentation?  

On May 23, 2007, at 11:23 AM, Tore Halset wrote:
> Hello.
> The DataContext are not thread-safe so you may experience random  
> problems if your app has a single DC used by two different threads.
> There are different ways to "solve" this issue.
>  A) Make sure each session only have one request at any time.  See  
>  B) Use a single DC for each thread. session bound data objects  
> must then be transferred using localObject() between contexts. Or  
> just store the objects ObjectId in the session.
>  C) Use child DC or peer DC. I have not tried this approach.
> I am sure someone else can come up with other variants.
> Regards,
>  - Tore.
> On May 23, 2007, at 03:30, Steve Wells wrote:
>> I guess the result could be hard to predict and test?  Are you  
>> suggesting
>> that I should wrap the block of dc == null {...} in a synchronized()?
>> Clearly my knowledge of this area is limited and I do appreciate your
>> guidance and questions.
>> Steve
>> On 23/05/07, Tore Halset <> wrote:
>>> On May 22, 2007, at 05:22, Steve Wells wrote:
>>> > My approach would be to have a simple per session DC and a global
>>> > web app
>>> > this stage, hardly seems dangerous, what could  
>>> possibly go
>>> > wrong?
>>> > ;)
>>> What if a user (session) issues two simultanous requests?
>>>   - Tore.

View raw message