JDO vs. Entity Beans: A Modest Proposal
Subject:   An approach
Date:   2002-03-06 04:33:25
From:   spruzens
Why not give entity bean writers the option of having their interfaces implement another interface, RemoteStreamable (perhaps someone could pick a better name). RemoteStreamable would have a single method:

public interface RemoteStreamable {

Entity beans inplementing RemoteStreamable have these characteristics:

1. When the first get or set is called on the interface, the current state of the entity is streamed to the client. The container may chose to lock the bean optimistically or pessimistically at this point.

2. All gets and sets operate on the client's local copy of the bean.

3. When the client calls the release() method, the bean's state is streamed back to the server for persistence.

4. Depending on how the server implements locking, a second client may have to block waiting for the first client to call release() (a problem if the first client never calls release()), or the second client may get an instance of the bean, with either client's release() calls throwing a ConcurrentModificationException if required.

Locking strategy would perhaps be set in a deployment descriptor.

RemoteStreamable entity beans in session bean facades would continue to inherit the transactionality of the method they are used in, with an implicit call to release() at the end of the session bean method (or indeed transaction boundary).