Rather then pull the context from the object I always pull from the
thread I am executing within:
public static ObjectContext getCayenneContext() {
try {
ObjectContext context = DataContext.getThreadObjectContext();
return context;
} catch (IllegalStateException ex) {
ObjectContext context = DataContext.createDataContext();
DataContext.bindThreadObjectContext(context);
return context;
}
}
This gives me reliable access to a common context for all requests
within a thread(request). Its fairly easy to create objects ad hoc and
then attach them to the session when your ready to commit. You can
also easily detach the object and reattach it when your ready to
commit it (and do comparisons etc).
Using the ThreadObjectContext() solved all of my context disconnects.
John-
On Wed, Jul 22, 2009 at 7:18 AM, Mike Kienenberger<mkienen..mail.com> wrote:
> To assign relationships between objects, they have to be in the same
> context. As Emanuele stated, it's hard to say what the best practice
> for wicket is since we haven't used it.
>
> In my web applications, I have typically either used a new DataContext
> per request, or reused the same DataContext for the lifetime of the
> session. It will depend on your needs. Sometimes I have created a
> "read-only" shared DataContext to store data that never or rarely
> changes, and then used localObject to copy a reference of that static
> data into my non-read-only DataContext.
>
>
> On Wed, Jul 22, 2009 at 9:47 AM, Reinout van Schouwen<reinou..mail.com> wrote:
>> Hi,
>>
>> 2009/7/22 Mike Kienenberger <mkienen..mail.com>:
>>> If you know that Person is not in a modified state, you can make a
>>> local copy of Person in your nameObj's data context.
>>
>> Thanks, Mike and Emanuele, getting the object context from the nameObj
>> indeed solves the problem.
>>
>> Is this something to be aware of at all times? I.e. when creating a
>> link between two objects, is it best practice to retrieve the
>> datacontext from either one, and handle both objects from that
>> context?
>>
>> --
>> Reinout van Schouwen
>> http://vanschouwen.info/
>>
>
This archive was generated by hypermail 2.0.0 : Wed Jul 22 2009 - 13:22:53 EDT