Folks,
We have to decide the strategy for integrating Cayenne with EBB-s. Let me outline the issues. Here is the scenario we need to support:
* Stateful session bean returns collection of Cayenne data objects to web container.
* Web container deletes and modifies objects, adds new ones and calls stateful EJB with the updated collection. Updates may be done to the attributes (setName(), set DOB()), as well as to the relationships (addAddress(), setToEmployer()).
* Changed collection is reconciled (somehow) with the Cayenne context in the bean and saved to the db.
First, what we DON'T need to be looking at. We don't need to bother with the resolving lazy relationships on the web container side through remote calls. If user would be using straight SQL, they would get only what they asked for in the query. The same with Cayenne data objects: if they need data in the relationships, they'd better use pre-fetching. If they didn't pre-fetch, they would get nice "HollowStateException" or something like that.
Now here are the issues.
1. Data Context is not sent remotely. Reference to DataContext in every data object is transient (meaning it is not going to be serialized and sent remotely). We need to handle reference to NULL DataContext gracefully, as it may be used in case of the HOLLOW state (is it only in case of the lazy relationships?). Is DataContext is used for anything else (except next item)?
2. We have problem creating new data objects on client (web container). To create a new object we need to register it with DataContext, which is not sent remotely (see prev item).
As we don't plan to handle concurrency and transaction management (taken care by EJB-s), these are the only issues I can think of. First issue can be solved by checking for NULL DataContext, which shouldn't be difficult. Creating new objects on the client side is the real problem. Here are couple ideas:
1. Make DataContext field in the Cayenne data objects non-transient and sending server DataContext to the client. Of course, it means that the whole tree of objects, including those not needed, will be sent out remotely, but we will have everything on client side! When new objects are added and the changed collection is sent back to the server (from web container to EJB container), the first thing EJB method would do is replace DataContext from server with the one received from client.
2. We may use different DataConext-s for client and server. I am not sure how exactly we will do it, but we may use writeObject()/readObject() and writeReplace()/readResolve() methods for substituting DataContext on the fly. To get this going we will need a singleton access to the server DataContext, so that the client DataContext could reconcile itself with the server DataContext as data is read.
3. We may require the call to prepare a collection for the serialization (something like DataContext.prepare()). This will a) create client DataContext referencing only the objects being sent across to web container b) set objects up so that they would use client DataContext during serialization rather than server DataContext. By the same token, when the data is received from the web container, we would require DataContext.reconcile() call, which would take client DataContext and make sure all the changes are copied to the server DataContext.
Did I miss any scenarios or show-stopping issues? Did I miss any solutions? Let's get some ideas on the table.
Misha
This archive was generated by hypermail 2.0.0 : Tue May 14 2002 - 19:05:34 EDT