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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. >>> > >
