Is this really a must of EJB 1.1 spec? I know of Inprise Application Server
doing this another way. If a client calls a
entity bean there (TX_REQUIRED), a "global" transaction is used. If it is
not existing, it's created. If it is there, it only
used (!). ALL calls now use this transaction. It is NOT closed between calls
(this would be TX_REQUIRES_NEW)! It is closed by
timeout. So, I would please you to tell me: Is it JOnAS specific that the
transaction is closed between calls, or is it
needed from the spec? All I read about TX_REQUIRED is, that a transaction is
used, but NOT that it had to be closed directly
after a call. I think that timeout solution of Inprise is quite OK for the
EJB 1.1 spec, and it would solve the problem!
The semantic of TX_REQUIRED is, as you said, that if
a transaction exists when the method is called, it will be
used for the method execution, and thus it will not be closed
at the end of the method (it will be closed by the client or
method who started it), else (if there is no transaction), a new
one is created for the method execution, but just for the duration of
the method execution. This is what is in EJB 1.1 (sorry for still refering
it),
and I have never heard about such a timeout mechanism.
In your case, since the client did not start any transaction
before calling getX, a new one is created, getX is executed,
and the "container performs the commit protocol before the
method result is sent to the client" (EJB 1.1, 16.6.2.2).
-> Francois, after all you wrote I believe you are right. I will look at the
EJB 1.1 spec (thank you for the link). Maybe I the problem is that I learned
EJB not from spec but from Inprise Docs and Inprise does something that is
not conform to the standard (what's quite likely, because I discussed some
points with the developer team there and after some weeks I saw that what
they told me to be a good feature to be on the official bug list...).
http://java.sun.com/products/ejb/
Another point is, I still do not know why you think that it is not ok to
have client caching. What is the point where my proposal would interfere
with EJB 1.1 spec? If GenIC would produce code to only do getXXX on an
entity bean only once in a transaction, what could be wrong? For the client,
nothing changes: It talks to a EJB 1.1 bean by unchanged interfaces, the
data is the same (for data cannot change inside a transaction to a CMP
entity bean), and for the server also nothing changes. Or is there a
limitation in EJB 1.1 spec that tell that a container may not cache CMP
entity bean calls in a transaction (I do not speak of caching of SBs or
caching over transaction boundaries).
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
