Philippe,
I used your sample application and configuration (two jonas servers, two
separate registries), and was able to reproduce the problem in both
Bean-managed and Container-Managed Transactions for the UserManager session
bean. Find attached the following logs from the "JonasUser" and the
"JonasUserManager" servers using JEREMIE:
JonasUserManager-BMTrans.log (Bean-Managed Transaction)
JonasUserManager-BMTrans-Run2.log (Bean-Managed Transaction, 2nd run --
restarted server, but not registry)
JonasUser-BMTrans.log (Bean-Managed Transaction)
JonasUser-BMTrans-Run2.log (Bean-Managed Transaction, 2nd run --
restarted
server, but not registry)
JonasUser-CMTrans.log (Container-Managed Transaction)
JonasUserManager-CMTrans.log (Container-Managed Transaction)
I have not yet tried to duplicate the tests using RMI, I'm unfamiliar with
configuring RMI but will get back to you once I have it configured jonas
properly and re-run the test.
Thanks,
Eric
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 7:53 AM
To: Eric Chang
Cc: [EMAIL PROTECTED]
Subject: Re: distributed transaction problem across jonas servers
Hi Eric,
it seems there is a bug we have to fix.
I have tried to reproduce your problem
but I have the same results with managed transaction or container
managed transaction in the stateless session bean.
I put in attachement the test I have written
I can describe it:
2 beans :
UserManager stateless session bean, bean managed transaction
User entity cmp transaction attributes Required
table.sql a script file to init the database
the directory tmp is used for launching the server jonasUser
it will work with the jeremie registry listening to port 1952
under the directory chang I launch another EJBServer witch
is working with another jeremie registry listening to another port .
UserManagerClient does to calls to UserManager.changeUser
UserManagerBean lookup at the other registry to obtain the User home
the User.ejbStore throws a RemoteException on the second call
Can you confirm me that this test reproduces your problem?
thanks,
Regards,
PS : I have not made the try with RMI. and you? have you got the same
result?
Eric Chang wrote:
>
> hello,
>
> I have encountered the following distributed transaction problem using the
> following configuration (jonas 2.3):
>
> I am using an entity bean that represents a user (bean-managed
persistence,
> container-managed transactions), with the following deployment descriptor:
>
> <enterprise-bean>
> <entity>
> <ejb-name>User</ejb-name>
> <persistence-type>Bean</persistence-type>
> ...
> </entity>
> </enterprise-bean>
> ...
> <assembly-descriptor>
> <container-transaction>
> <method>
> <ejb-name>User</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> </assembly-descriptor>
>
> There is also a UserManager stateless session bean (bean-managed
> transactions) that provides a facade to the User bean:
>
> <enterprise-bean>
> <session>
> <ejb-name>UserManager</ejb-name>
> <session-type>Stateless</session-type>
> <transaction-type>Bean</transaction-type>
> ...
> </session>
> </enterprise-bean>
>
> The User Bean and the UserManager Bean operate in two separate jonas
servers
> on two separate machines, with separate JEREMIE registries and local
> Transaction Managers (jonas.tm.remote = false). The User Bean is running
in
> the "Jonas-User" server and the UserManager Bean is running in the
> "Jonas-UserManager" server.
>
> The User Bean's ejbStore() method modifies the database programmatically.
> There is also a method, changeUser(..), that allows a client of the User
> Bean to change the internal values of the Bean. The UserManager Bean
calls
> User.changeUser() within a bean-managed transaction:
>
> UserManagerBean.java:
>
> public void changeUser(..)
>
> ...
> try {
> javax.transaction.UserTransaction trans =
> this.sessionContext.getUserTransaction();
> User user = userHome.findByPrimaryKey(userId);
>
> trans.begin();
> ...
> user.changeUser(..);
> ...
> trans.commit;
> System.out.println("Transaction commmited");
> return;
> } catch (Exception e) {
> try {
> trans.rollback;
> } catch (Exception e2) { }
> }
> }
>
> (Once again, the User is running in the jonas named "JonasUser" and the
> UserManager is in the jonas container "JonasUserManager")
> Since the <trans-attribute> on the method User.changeUser(..) is
"Required",
> I expect the User.changeUser() method to use the existing transaction
> ("trans") explicity declared in the code above. In other words, the call
to
> trans.commit() should cause the "JonasUser" container to call
> User.ejbStore() after User.changeUser() has modified the entity bean's
> state. However, I've found that when an exception is thrown in
> User.ejbStore() -- say an SQLException due to an errant database
> operation -- the demarcated transaction in the UserManager Bean code above
> commits without throwing an exception, and at some point after the calling
> method UserManagerBean.changeUser() returns, I get the following
exception:
>
> JContextEntity.storeIfModified raised EJBException
> Rollback during beforeCompletion in SubCoordinator.prepare
> Resource replied rollback to prepare
> JTM: Cannot rollback resource:
> java.rmi.MarshalException: error during marshalling/unmarshalling by stub;
> nested exception is:
> org.omg.CORBA.OBJECT_NOT_EXIST: minor code: 0 completed: No
> org.omg.CORBA.OBJECT_NOT_EXIST: minor code: 0 completed: No
> at java.lang.Class.newInstance0(Native Method)
> at java.lang.Class.newInstance(Class.java:237)
> at
>
org.objectweb.david.libs.protocols.giop.GIOPProtocol$ReplyHolder.listen(GIOP
> Protocol.java:933)
> at
>
org.objectweb.jonas_tm.SubCoordinator_Stub.rollback(SubCoordinator_Stub.java
> :176)
> at
> org.objectweb.jonas_tm.ControlImpl.do_rollback(ControlImpl.java:911)
> at org.objectweb.jonas_tm.ControlImpl.commit(ControlImpl.java:425)
> at
> org.objectweb.jonas_tm.ControlImpl_Skel.send(ControlImpl_Skel.java:51)
> at
>
org.objectweb.david.libs.protocols.giop.GIOPProtocol$ServerSession_Low.send(
> GIOPProtocol.java:621)
> at
>
org.objectweb.jonathan.libs.protocols.tcpip.TcpIpProtocol$Session.run(TcpIpP
> rotocol.java:396)
> at
>
org.objectweb.jonathan.libs.resources.JScheduler$JJob.run(JScheduler.java:26
> 5)
>
> It appears that by the time the container calls User.ejbStore(), the
> original transaction has been committed and cleaned up. However, if i
> modify the UserManager Bean deployment descriptor to use Container-managed
> transactions:
>
> <enterprise-bean>
> <session>
> <ejb-name>UserManager</ejb-name>
> <session-type>Stateless</session-type>
> <transaction-type>Container</transaction-type>
> ...
> </session>
> </enterprise-bean>
> <assembly-descriptor>
> <container-transaction>
> <method>
> <ejb-name>UserManager</ejb-name>
> <method-name>changeUser</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> </assembly-descriptor>
>
> and i remove the demarcated transations from UserManagerBean.changeUser(),
> things seem to work correctly. That is, if User.ejbStore() throws an
> exception, i get the following output:
>
> JContextEntity.storeIfModified raised EJBException
> Rollback during beforeCompletion in SubCoordinator.commit_one_phase
> Commit local transaction -> rolled back!
>
> Is this difference in bean-managed and container-managed transactions
> expected?
>
> Thanks for your help,
>
> Eric
>
> ----
> 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".
--
Philippe
Philippe Coq Evidian Phone: (33) 04 76 29 78 49
Bull S.A - 1 rue de Provence - 38432 Echirolles Cedex France
Download our EJBServer at http://www.objectweb.org
JonasUserManager-BMTrans.log
JonasUser-BMTrans.log
JonasUser-BMTrans-Run2.log
JonasUserManager-BMTrans.log
JonasUserManager-BMTrans-Run2.log
JonasUserManager-CMTrans.log
JonasUser-CMTrans.log
