OK based on some of these suggestions I'm trying to establish some best
practice here for these scenarios.
Using an example of User signup (creating and updating objects) and login
(reading objects) on a website
Use case 1: Signup
The user will select the signup link and be shown a page of basic info such
as username and password.
In code: return (UserInfo) DataContext.getThreadDataContext
().createChildDataContext().createAndRegisterNewObject(UserInfo.class);
Initialised UserInfo is bound to a web form
User fills in details and these are set in the bound UserInfo Object
On Submit:
// Set any UserInfo fields and relationships
userInfo.getDataContext().commitChanges();
Use Case 2: Login
User submits form
As this is only a search is it ok to just?:
SelectQuery query = new SelectQuery(UserInfo.class, expression);
List result = DataContext.getThreadDataContext().performQuery(query);
Is this making sense and on the right track?
On 23/05/07, Andrus Adamchik <andru..bjectstyle.org> wrote:
>
> 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 <halse..vv.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.
> >>>
> >
> >
>
>
This archive was generated by hypermail 2.0.0 : Thu May 24 2007 - 03:07:44 EDT