Basically that's the case. I was thinking that in instances where
the result set will generally return quickly, I was going to just use
SessionBean's that commited the data directly to avoid the overhead of
serializing and deserializing through JMS queues/MDB's.
Would it make sense to have that wedge class implementing
Externalizable for all my persistent classes and then only use it in
instances where the data goes through the JMS queue's and then for
simple cases use the getThreadDataContext() method? In almost all the
cases where I'm using JMS and MDB's, I'm doing and aggregate Select on
multiple data sources and I'm not committing anything, just read only
data. The commits are generally simple and don't necesarrily
require going through JMS. The only reason to use JMS is because
some of the data sources are external and I have no way of knowing if
they're going to return a result at all.
Also what is DataContext.localObjects() doing? Is it taking the List
and inflating everything including relationships and returning a new
list because that seems to work fine in my prototype but again it's
not the solution to the problem - just curious.
Thanks,
Mike
On Tue, 8 Mar 2005 16:11:01 -0500 (EST), Andrus Adamchik
<andru..bjectstyle.org> wrote:
> Hmm... in this scenario it looks like Cayenne as such is only used at the
> MDB layer (unless I am missing something)... So it may actually make sense
> to pass completely inflated objects (with all relationships resolved)
> through the layers.
>
> So I guess we can turn around and detach objects from DataContext, passing
> them around as read-only graph. I haven't tried that, but I think the
> easiest solution would be to create a wedge superclass (sitting between
> CayenneDataObject and your custom classes) that implements Externalizable
> interface, storing both "objectId" and "values" ivars.
>
> And if my assumption is wrong, and you inflate/modify/commit your objects
> across all three layers, then we'll have to worry about the threads ;-)
>
> Andrus
>
>
> > 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 - 17:01:45 EST