Ok.
Found some code.
Basically, I'm serializing a "DAO" class whose state is pretty much
just a DataContext.
private void writeObject(java.io.ObjectOutputStream out)
throws IOException
{
out.writeObject(this.childDataContext);
}
private void readObject(java.io.ObjectInputStream in) throws
IOException, ClassNotFoundException
{
this.childDataContext = (DataContext)in.readObject();
childDataContext.setChannel(super.threadDataContext().getParentDataDomain());
this.childDataContext.setUserProperty("temporary", Boolean.TRUE);
}
So it looks like the only trick is setting the channel on unserialization.
I don't remember the particulars of why I mark the context as
temporary on unserialization.
I don't see it used for anything other than debugging elsewhere.
On Wed, May 5, 2010 at 5:27 PM, Mike Kienenberger <mkienen..mail.com> wrote:
> I did find some tests written which explicitly serialized DataContext.
> Apparently I was serializing DataContext at one point, and had some
> issue where creating a data object, then deleting that data object
> without committing, and it was causing an issue with serialized
> DataContexts.
>
> On Wed, May 5, 2010 at 5:10 PM, Mike Kienenberger <mkienen..mail.com> wrote:
>> Hmm. Unfortunately, I can't remember if my issue with that project
>> was that the DataContext wasn't being serialized or that it was and I
>> didn't want it to. And this was 1.2, so the behavior may have changed
>> since then.
>>
>> But in either case, it seems pretty trivial.
>>
>> In the case of it being serialized, it already does what you want
>>
>> In the case of it not being serialized, you'd create a new DataContext
>> and dump in all of the serialized objects you had from the original
>> DataContext.
>>
>> I don't think there's any state that needs to be saved for a
>> DataContext other than the DataObjects it contains. Maybe you'd also
>> need to save the initial fetched object snapshots if you were working
>> with optimistic locking.
>>
>> All I can say for sure is that I did a JSF project where we saved the
>> uncommitted DataObjects out as client-side data (serialized into the
>> generated html), then read them back in on the next request. The
>> data would survive application restarts, so it should be equivalent to
>> moving it to another session or another server.
>>
>> I tried glancing through what project source code I had laying around,
>> but I couldn't find the code that dealt with the serialization -- too
>> many project modules to look through.
>>
>> On Wed, May 5, 2010 at 4:57 PM, Michael Gentry <mgentr..asslight.net> wrote:
>>> My experience with Tapestry (4 & 5) serializing a DataObject to the
>>> HTML (which it does by default when you have a loop in a form) is that
>>> the deserializing of the DataObject (on the subsequent
>>> request/response) gives you a DataObject that is disassociated from
>>> the DataContext (not good). Perhaps if the DataContext went along for
>>> the ride all would be well ...
>>>
>>> Thanks,
>>>
>>> mrg
>>>
>>>
>>> On Wed, May 5, 2010 at 4:53 PM, Mike Kienenberger <mkienen..mail.com> wrote:
>>>> No direct experience, but I know you can serialize DataObjects and I'm
>>>> 99% certain you can serialize DataContexts. I think I did this in
>>>> one project in the past to preserve state between requests rather than
>>>> saving state in the sessions.
>>>>
>>>> On Wed, May 5, 2010 at 4:37 PM, Michael Gentry <mgentr..asslight.net> wrote:
>>>>> Someone on another project here asked me if Cayenne works with session
>>>>> replication (with 1+ user DataContext objects in the HttpSession)
>>>>> between application servers (such as JBoss). They have a project
>>>>> where they are running N instances of JBoss and they replicate/sync
>>>>> the session data across the JBoss instances. They are curious if the
>>>>> DataContext + DataObjects will replicate correctly. I've never
>>>>> attempted to do so and am not sure. Does anyone have experience with
>>>>> this?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> mrg
>>>>>
>>>>
>>>
>>
>
This archive was generated by hypermail 2.0.0 : Wed May 05 2010 - 17:43:00 EDT