Bryan, Fredrik,
What Bryan describes is likely a serialization issue with Tapestry
discussed here -
http://objectstyle.org/cayenne/lists/cayenne-user/2005/03/0105.html (there
is actually two somewhat related discussion within the same thread, see
our exchange with Robert).
When I get some more time (when would that be?), I'd like to try those
alternative deserialization tecniques... AFAIK there is no problems with
"vanilla" web apps. Tapestry does too many "weird" things internally, so I
am not surprised that it behaves differently.
Anyway, the reason why we recommend to have a session-scoped DataContext
is exactly to address all of Fredrik's concerns ("Do you have to make sure
the status is not new or updated? So not to accidentally commit something
later on or having some ID generation conflict? Or what if several people
store the same object in their sessions, hmm?")!!! That's what DataContext
does automaticaly - preventing sessions mixup and managing persistence
state.
Again, the point is that it should be 100% safe to store DataObjects in
the session. If it doesn't work, it should be treated as a bug in Cayenne
(I guess we need to log the Tapestry case in JIRA).
Andrus
> > what if several people store the same object in their sessions, hmm?
>
> Funny you should ask that. I've been storing a DataObject in the
> session (well, in the Tapestry visit which ends up in the session). I
> was storing the object that represents the logged-in user. This was
> working fine all during development, until yesterday our Q/A guy did
> some stress testing. He started two sessions as the same user, by
> logging in from two different browsers. After hitting a few big pages
> alternating between browsers, he got weird exceptions because the user
> object became transient... its DataContext became null.
>
> So... I was coming to the conclusion that I can't do that. Or else I
> have to be very careful when the user object is retrieved, and be
> prepared to re-fetch or re-register it. Is that a good enough fix?
> Maybe I should store only the user ID and _always_ refetch it? That
> seems kind of wasteful since the object is used on almost every page and
> double logins will be rare.
>
> While looking for a small test case, I noticed that the new "Tapestry
> Blog" example follows this technique -- the Visit stores a UserAccount
> object.
>
>
> ----- Original Message -----
> From: "Fredrik Liden" <flide..ranslate.com>
> To: <cayenne-use..bjectstyle.org>
> Sent: Tuesday, March 15, 2005 2:27 PM
> Subject: RE: Storing a copy of a DataObject in the session
>
>
> Are you actually storing live DataObjects in the session? and it's
> keeping it's relationship with the Context?
>
> Do you have to make sure the status is not new or updated? So not to
> accidentally commit something later on or having some ID generation
> conflict? Or what if several people store the same object in their
> sessions, hmm?
>
> So by storing a bunch of DataObjects in a session you don't need any
> beans like struts formbeans to maintain state? That sounds pretty good!
>
> /Fredrik
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:mkienen..laska.net]
> Sent: Monday, March 14, 2005 10:44 AM
> To: cayenne-use..bjectstyle.org
> Cc: cayenne-use..bjectstyle.org
> Subject: Re: Storing a copy of a DataObject in the session
>
> Fredrik Liden <flide..ranslate.com> wrote:
>> Is there a way to clone a DataObject to be an independent read-only
>> object and store it in the session. That way I don't have to refetch
> the
>> DataObject everytime I want to print one of the values. I'm guessing
>> it's not good to store the DataObject in the session because of
> locking
>> etc.
>
> I store DataObjects in the session without problem. There are no
> locking
> issues that I am aware of.
>
> -Mike
This archive was generated by hypermail 2.0.0 : Tue Mar 15 2005 - 15:47:49 EST