Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <1C9372CF-9C56-42F0-AAF4-F2A2257B46A8@pvv.ntnu.no>
References: <af254f880705202123t1858ff9eife25a6ab9d23844d@mail.gmail.com>
 <47F4CA8C-7E07-4558-85EE-D58765C10EED@pvv.ntnu.no>
 <af254f880705211636ife18626y4d6110d2ce52a996@mail.gmail.com>
 <8666FDF1-0C78-4213-8138-0431AE279865@puregumption.com>
 <af254f880705212022l6f9e0b2cu16592bd88b333c52@mail.gmail.com>
 <75A39230-927B-4AFC-A48D-91BE93556D5B@pvv.ntnu.no>
 <af254f880705221830n74877833o36db92364ac7e70a@mail.gmail.com>
 <1C9372CF-9C56-42F0-AAF4-F2A2257B46A8@pvv.ntnu.no>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DB761DC0-9CB6-43A1-82CB-E38C07726A66@objectstyle.org>
Content-Transfer-Encoding: 7bit
From: Andrus Adamchik <andrus@objectstyle.org>
Subject: Re: Obtaining DataContext in ZK
Date: Wed, 23 May 2007 15:50:57 +0300
To: user@cayenne.apache.org

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.

Thanks
Andrus

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?  
Thoughts?


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  
> http://tinyurl.com/2r4kcy
>  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 <halset@pvv.ntnu.no> 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
>>> > one...at this stage, hardly seems dangerous, what could  
>>> possibly go
>>> > wrong?
>>> > ;)
>>>
>>> What if a user (session) issues two simultanous requests?
>>>
>>>   - Tore.
>>>
>
>