[EMAIL PROTECTED] wrote:
The semantic of TX_REQUIRED is, as you said, that if
> 2) Transactional behaviour and entity beans
>
> This is an explanation of the behaviour that you described
> in your last e-mail and that I recall below : you have an entity
> bean with the TX_REQUIRED attribute defined for each
> method, and your client does not start any transaction and does:
> myEntity.getX();
> myEntity.getY();
>
> and you can see on the server the "traces"
> myEntity.ejbLoad();
> myEntity.getX();
> myEntity.ejbStore(); // THAT IS NOT NEEDED YOU THINK
> myEntity.ejbLoad();
> myEntity.getY();
> myEntity.ejbStore();
>
> You say the ejbStore in the middle is not needed. You're right
> but having defined the TX_REQUIRED attribute (I think this
> is what you call "NeedsTransaction") on the beanYes, I mean TX_REQUIRED
> methods (getX and getY) and not starting a method in the client
> has the following effect:
> - the container will start a new transaction T1 just for executing
> getX, thus executing ejbLoad, and ejbStore (this last operation
> at the T1 commit time),
> - the container will start a new transaction T2 for executing getY,
> .....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!
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).
Sure, better solution would be to call this from inside an SB's TX_REQUIRES_NEW method, but this clearly points out that you
can read EJB 1.1 spec THIS way O R THAT way...!
I don't think so.
> So the ejbLoad and ejbStore you see are perfectly normal. This
> is a behaviour according to your transaction attributes. The way to
> execute getX and getY in the same transaction (and thus avoiding
> the "middle" ejbStore) is to start a transaction embedding the 2 calls
> from the client, OR to perform the two calls in a method of a session
> bean (that will have the TX_REQUIRES_NEW attribute), and to
> call this method from the client (which is related to the discussion
> above, 1-b).
> In the last version of JOnAS, you may also be able to avoid
> the "middle" ejbStore by using the TX_SUPPORTS or
> TX_NOT_SUPPORTED on your methods, and by not starting
> a transaction on the client. Thus your methods will execute outside
> any transaction.But I WANT execution INSIDE a transaction.
So you have to create one, explicitely (in your client)
or implicitely (by the way of TX attributes on your methods).
As I said above, TX_REQUIRED has nothing to doIs it REALLY wanted EXPLICITELY in the EJB 1.1 spec, that in TX_REQUIRES (not _NEW) to close between calls and NOT doing only
a timeout? So what Inprise Application Server 4 does has to be quite wrong (and they should not be proud of their
performance).
with closing transaction between calls. If a transaction context
exists, it will be used, else a new transaction is created for
the method execution duration.
I'm not sure to understand this concept of timeout. If you
mean that a transaction is created for a TX_REQUIRED method
execution (because there was no existing tx) and then closed by
timeout and not at the end of the method, in case another
method (tx_required) could use it, then I can affirm this is
absolutely not a standard (EJB 1.1) and certainly not
even a coherent behaviour !
For I do not have EJB 1.1 specs here, I would really please you to read this in detail and with my interpretion in mind. Or
could you please send me EJB 1.1 specs? So I will read before I make new suggestions.
http://java.sun.com/products/ejb/
Regards,
François
--
==================================================================
Francois EXERTIER Evidian
(Groupe Bull)
1, rue de Provence, BP 208, 38432
Echirolles cedex, FRANCE
mailto:[EMAIL PROTECTED]
http://www.evidian.com/jonas http://www.objectweb.org/jonas
Tel: +33 (0)4 76 29 71 51 - Fax:
+33 (0)4 76 29 77 30
==================================================================
