Rickard,
You touched on two issues:
1. RMI/EJB should have a mechanism to allow client side stubs to cache
state on the client.
2. Explicit context propagation.
If I didn't understand these right, ignore the rest of the message!
A number of RMI/CORBA systems give you smart-stub support for client
side caching. The API can be made very transparent. It works if the
object on the server is not shared.
If it is shared, however, the cache is more a hindrance than a
help. You as an application programmer have to deal with cache
coherence. You are far better off writing a session bean to interface
to your entity beans on the server ... this way the server manages the
transactional cache and you are at least able to make local calls.
Sure, one could extend the transactional cache management to the
client, as OODBs are wont to do, but that scales *extremely*
poorly. Most TP systems don't even do caching on the server. A
high-end Tuxedo installation may have thousands of processes talking
to the database, and there is no state maintained on the middle tier.
How were you planning to deal with cache coherence? Note that an event
mechanism to maintain the cache doesn't quite cut it because of
significant propagation delays.
You also touched on explicit context propagation .. passing the
context as an additional parameter. In general, all TP systems that
I'm aware of don't allow you to do this because there is no way for
the system to enforce checked transaction behavior (where the system
checks if all work pending in that transaction is over before it is
committed) In other words, say you are able to hand over the
transactional context to another thread and then return. If the caller
has no clue about this hand-off and issues a commit, the transaction
may or may not include the work initiated by the other thread. If the
client does know about this hand-off, it is left up to the app
programmer to ensure that all the work initiated in that transaction
is over before a commit is issued. Although CORBA OTS allows explicit
transaction propagation, I'm told that it went into the spec over
serious objections.
- Sriram
________________________________________________________________________
Principal Engineer BEA/WebLogic, San Francisco www.weblogic.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
