Hi Derek,
let me address some of your issues:
>
- Rich Clients and cross-VM communication
Every now and then the discussions pop up on cayenne-lists to have 3-tier
rich client support (kind of like current WebObjects Java Client
architecture with a transport like webservices or something) and have a
"distributed" DataContext optimized for caching and data transfer... Just
the other day when we met with Tore Halset, this poped up again. I guess
at some point we get acrictical mass and of people interested in this, so
we can build it as a part of Cayenne.
Right now you can serialize the whole DataContext, push it to the server,
and do commit there. Actually pretty can be done pretty easy, and you
don't have to write any DTO!!
> Am I right in thinking that life will be simpler if I
> avoid calls to non local session beans as then I can (easily) keep using
> the same DataContext?
Yes.
> BTW: Any
> chance that the sample code mentioned in
> http://objectstyle.org/cayenne/lists/cayenne-user/2004/06/0202.html is
> available yet :-)
A prototype is being tested right now (not by me :-)), AFAIK it will be
ready very soon.
- Transactions and JMS:
You can either use a TransactionDelegate.didCommit() method or setup
Cayenne to use external transactions and use J2EE distributed transaction
features provided by container.
- JMS Adapter.
It is totally possible to write a JMS adapter. I started some work on
LDAP, but put it on hold for now as my customer lost interest in that for
the time being.
Two things to reimplement are DataNode and DbAdapter interface. Right now
both have JDBC dependencies... just ignore those. Eventually (2.0) this
will be refactored to make it cleaner so that DbAdapter becomes a JDBC
plugin for DataNode subclass called JDBCDataNode, and DataNode will become
100% JDBC agnostic... Right now you would use your custom DbAdapter as a
factory for you custom DataNode, say JMSDataNode. In JMSDataNode
reimplement "performQueries(...)" to send out JMS message for a particular
query.
Not sure how you would handle the receiving side, as Cayenne (or any other
ORM) implements "pull" data model.
Lets continue this discussion on cayenne-devel list if you decide to go
along with that.
>
> (3) What are the issues to be aware of when my session gets
> serialised/deserialised by the container?
Ideally none... Just keep in mind that when DataContext is serialized, its
ObjectStore is seriazlialized too, so there maybe quiet a few cached
objects hanging around...
>
> (4) W have our own id generator, and part of its function is to encode
> inheritance heirarchies into the primary key values where necessary.
> This prevents having to do a fetch to find the type of a FK before
> loading the FK - does Cayenne do the double fetch approach, and if so,
> is there a way to make use of the encoding in the ids (someone I knew
> did this in EOF several years back). Note: we have the type field as
> well (for non FK lookup queries etc).
Let me think about this one... I'll try to get back to you on that later..
Andrus
This archive was generated by hypermail 2.0.0 : Wed Jun 30 2004 - 14:40:57 EDT