Hi Andrus -
Thanks for clearing this up a bit. I was getting concerned that
attaching the DataContext refetched from the database! To get around
this at the moment I used DataContext.localObjects(List) which works
but I don't get the feeling this is what I want to do.
My situation as I said a Tapestry front end. This front end WAR is
not in the EAR file with all my EJB code as I'd like to keep that
separate unless it makes more sense to couple it all. My EAR file
contains the Session facade and Message Driven Beans. The Session
Facade calls multiple MDB's which either pull data from a RDBMS or a
WebServices feed or any number of data sources and aggregates them and
returns this to the Tapestry client for display. So in essence there
are really 2 clients. There's the client that is on the response side
of the call the MDB which has to deserialize the object graph and then
puts that into a data structure that the is passed onto what I'll call
the second client which is Tapestry application.
So if this makes any sense :-), will the
DataContext.getThreadDataContext() work in this complex of a pipeline?
I'm not all that familiar with what it does other then that I
understand the basic concept but I'm not sure how Thread's work in the
context of passing from a webapp to an SessionBean to a
MessageDrivenBean and back to through to the webapp. It seems to me
that at some point in the transaction (probably the MDB) the thread
gets decoupled from the request since it's an asynchronous mechanism.
But I'm not sure.
Any thoughts on the best practice for something like this?
BTW, I really love Cayenne so far. For lack of a better term it
"feels" much more intuitive then Hibernate. Plus I really like not
having to catch HibernateException everywhere! Thanks!
Mike
On Tue, 8 Mar 2005 13:57:13 -0500 (EST), Andrus Adamchik
<andru..bjectstyle.org> wrote:
> Actually DataObject serialization mechanism is very efficient, so what you
> see is not a handicap, but a feature... The idea is that unless object is
> modified, there is no need to write its properties, as on deserialization
> it will attach to a DataContext/ObjectStore/underlying cache that will
> provide missing values on demand.
>
> This implies that a DataContext/ObjectStore make sense on the
> deserialization side (client side in your case), so the most common
> pattern is serializing the whole DataContext. I recommend doing that.
>
> If this is not desirable (no Cayenne on the client) then you will need to
> do some tweaking ... we can discuss options further.
>
> Andrus
>
>
> > OK - I finally found some stuff after googling and I'm a bit nervous
> > that from what I've read you need to re-attach a DataContext to each
> > object in the list of results that have been serialized. This seems on
> > the surface to be a severe handicap but I'm still not sure what the best
> > practice is for this type of problem.
> >
> >
> > On Tue, 8 Mar 2005 10:41:26 -0600, Michael Engelhart
> > <moosebrookfar..mail.com> wrote:
> >> Hi -
> >>
> >> I just ported my Hibernate based JBoss application to use Cayenne and
> >> am finding some strange problems which I think are due to
> >> serialization issues. I am using Message Driven Beans to request
> >> multiple database lookups per request. MDB's serialize the
> >> request/response and then deserialize to get the data out. This
> >> worked fine with Hibernate.
> >> With Cayenne, the data is fine before the data is serialized and
> >> stuffed into the response but when I log the returned ArrayList from
> >> the MDB, all the values are null except for the objectId.
> >>
> >> I can't easily follow what's going on with CayenneDataObject classes
> >> as they implement DataObject which is a superclass of
> >> java.io.Serializable, java.io.Serializable and XMLSerializable.
> >>
> >> Any advice would be appreciated.
> >>
> >> Thanks
> >> Mike
>
>
This archive was generated by hypermail 2.0.0 : Tue Mar 08 2005 - 14:22:15 EST