Re: Transaction problems

2001-07-16 Thread Christian Bagnoli

Dear Philip,

thanks for the help.
The missing trans-attribute is due to a 'cutpaste' error writing
the letter. I'm very interessed to see your working code.

thanks a lot.

Christian
 
- Original Message - 
From: [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Friday, July 13, 2001 6:14 PM
Subject: Re: Transaction problems


 
 Hi Christian,
 Frankly we have the same problem, trying to access the entity bean
 through a session bean and not being able to rollback. However
 rollback is working perfectly fine in stateful/stateless session bean.
 
 One thing which I noticed in your xml file is that you have not given
 the tranas-attribute 'Required'. You have to do that in order to get
 at least the stateless or stateful beans to work on transactions. E.g.
 do two sql 'inserts' in one session bean in one method and if one
 fails throw EJBException and the rollback happens.
 
 But in the case of an entity bean being accessed by a session bean, if
 the entity throws an EJBException in the ejbStore() that is not being
 caught by the session bean and so the rollback does not occur.
 
 If you want the code for the session beans working with rollback, I
 can send it to you. I have to thank Mr Rob Lapenese for that bit of
 help.
 
 Kind Regards
 Aby Philip
 
 





RE: Transaction problems

2001-07-13 Thread J Davis

We would also be interested in a solution to this problem as we have
encountered the same thing.  We are using 1.5.2 and Oracle 8.1.6 for our
situation.
We have also run into an issue where if you start a transaction and
inside hit a lot of different data/ejbs the Orion server maxes out it's
CURSOR allocation to oracle.  It creates a new connection and continues
on, but the error is thrown to the logs and can cause some code to skip
steps (due to catching the exception). We were assuming that since the
transaction was still open Orion was not closing any cursors to wait for
a commit, but we don't really know what is going on in the background.

Any ideas?

Greg


-Original Message-
From: Christian Bagnoli [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 13, 2001 6:00 AM
To: Orion-Interest
Subject: Transaction problems


Hi,

we're implementing an entity bean with transactional (container managed)
methods. This bean is accessed by
a session statefull bean. We have transactional problem when a method
fails
(that is throws an EJBException) because orion doesn't rollback the
transaction.
Does anybody figure out how to make orion rollback the transaction?
We have also tried with a session stateless/stateful having the same
problem
.
Also implementing the SessionSycronization interface doesn't trap the
transaction
boundaries.

Our data-source.xml is:

data-source
  class=com.evermind.sql.DriverManagerDataSource
  name=SetmoveDS
  location=jdbc/SetmoveDS
  xa-location=jdbc/xa/MySetmoveDS
  ejb-location=jdbc/myEJBDS
  connection-driver=oracle.jdbc.OracleDriver
  username=test
  password=test
  url=jdbc:oracle:thin:test/test@testsun:1521:test
  inactivity-timeout=30
 /

we use orion 1.5.2.

the ejb-jar.xml is:
.
 session
   display-nameLogEntJAR/display-name
   descriptionLogEntJAR/description
   ejb-nameMyLogEnt/ejb-name
   homesetmove.beans.logica.LogEntHome/home
   remotesetmove.beans.logica.LogEnt/remote
   ejb-classsetmove.beans.logica.LogEntEJB/ejb-class
   session-typeStateful/session-type
   transaction-typeContainer/transaction-type
   ejb-ref
ejb-ref-nameMyEntUtente/ejb-ref-name
ejb-ref-typeEntity/ejb-ref-type
homesetmove.beans.logica.EntUtenteHome/home
remotesetmove.beans.logica.EntUtente/remote
   /ejb-ref
  /session
.
  entity
   display-nameEntUtenteJAR/display-name
   descriptionEntUtenteJAR/description
   ejb-nameMyEntUtente/ejb-name
   homesetmove.beans.logica.EntUtenteHome/home
   remotesetmove.beans.logica.EntUtente/remote
   ejb-classsetmove.beans.logica.EntUtenteEJB/ejb-class
   persistence-typeBean/persistence-type
   prim-key-classjava.lang.String/prim-key-class
   reentrantfalse/reentrant
   resource-ref
descriptiondescription/description
res-ref-namejdbc/SetmoveDS/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
   /resource-ref
  /entity
.
container-transaction
method
ejb-nameLogEntEJB/ejb-name
method-name*/method-name
   /method
   method
ejb-nameEntUtenteEJB/ejb-name
method-name*/method-name
   /method
  /container-transaction

thanks a lot.

Christian








Re: Transaction problems

2001-07-13 Thread Rafael Alvarez

Hello Christian,
The ejb-name tag in method must match the ejb-name in entity
or session. Also, specify a trans-attribute.

Try putting this in your ejb-jar.xml:

container-transaction
  method
ejb-nameMyLogEnt/ejb-name
method-name*/method-name
trans-attributeRequired/trans-attribute
  /method
  method
 ejb-nameMyEntUtente/ejb-name
 method-name*/method-name
 trans-attributeRequired/trans-attribute
  /method
/container-transaction





-- 
Best regards,
 Rafaelmailto:[EMAIL PROTECTED]






Re: Transaction problems

2001-07-13 Thread aby


Hi Christian,
Frankly we have the same problem, trying to access the entity bean
through a session bean and not being able to rollback. However
rollback is working perfectly fine in stateful/stateless session bean.

One thing which I noticed in your xml file is that you have not given
the tranas-attribute 'Required'. You have to do that in order to get
at least the stateless or stateful beans to work on transactions. E.g.
do two sql 'inserts' in one session bean in one method and if one
fails throw EJBException and the rollback happens.

But in the case of an entity bean being accessed by a session bean, if
the entity throws an EJBException in the ejbStore() that is not being
caught by the session bean and so the rollback does not occur.

If you want the code for the session beans working with rollback, I
can send it to you. I have to thank Mr Rob Lapenese for that bit of
help.

Kind Regards
Aby Philip





RE: Transaction problems

2001-07-13 Thread Jon Rue

As far as I have seen Orion behaves as per spec in regard to transactions. I
am not sure what the default transaction type Orion will assume if you do
not explicitly declare one in the ejb-jar.xml file but I imagine it defaults
to supports. You should explicitly declare your transaction attribute to
required in order to ensure that the session beans join the transaction of
the entity beans. 

Like so:

container-transaction
  method
ejb-nameLogEntEJB/ejb-name
method-name*/method-name
trans-attributeRequired/trans-attribute
  /method
  method
ejb-nameEntUtenteEJB/ejb-name
method-name*/method-name
trans-attributeRequired/trans-attribute
  /method
/container-transaction

Cheers,
-Jon


-Original Message-
From: Christian Bagnoli [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 13, 2001 5:00 AM
To: Orion-Interest
Subject: Transaction problems


Hi,

we're implementing an entity bean with transactional (container managed)
methods. This bean is accessed by
a session statefull bean. We have transactional problem when a method fails
(that is throws an EJBException) because orion doesn't rollback the
transaction.
Does anybody figure out how to make orion rollback the transaction?
We have also tried with a session stateless/stateful having the same problem
.
Also implementing the SessionSycronization interface doesn't trap the
transaction
boundaries.

Our data-source.xml is:

data-source
  class=com.evermind.sql.DriverManagerDataSource
  name=SetmoveDS
  location=jdbc/SetmoveDS
  xa-location=jdbc/xa/MySetmoveDS
  ejb-location=jdbc/myEJBDS
  connection-driver=oracle.jdbc.OracleDriver
  username=test
  password=test
  url=jdbc:oracle:thin:test/test@testsun:1521:test
  inactivity-timeout=30
 /

we use orion 1.5.2.

the ejb-jar.xml is:
.
 session
   display-nameLogEntJAR/display-name
   descriptionLogEntJAR/description
   ejb-nameMyLogEnt/ejb-name
   homesetmove.beans.logica.LogEntHome/home
   remotesetmove.beans.logica.LogEnt/remote
   ejb-classsetmove.beans.logica.LogEntEJB/ejb-class
   session-typeStateful/session-type
   transaction-typeContainer/transaction-type
   ejb-ref
ejb-ref-nameMyEntUtente/ejb-ref-name
ejb-ref-typeEntity/ejb-ref-type
homesetmove.beans.logica.EntUtenteHome/home
remotesetmove.beans.logica.EntUtente/remote
   /ejb-ref
  /session
.
  entity
   display-nameEntUtenteJAR/display-name
   descriptionEntUtenteJAR/description
   ejb-nameMyEntUtente/ejb-name
   homesetmove.beans.logica.EntUtenteHome/home
   remotesetmove.beans.logica.EntUtente/remote
   ejb-classsetmove.beans.logica.EntUtenteEJB/ejb-class
   persistence-typeBean/persistence-type
   prim-key-classjava.lang.String/prim-key-class
   reentrantfalse/reentrant
   resource-ref
descriptiondescription/description
res-ref-namejdbc/SetmoveDS/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
   /resource-ref
  /entity
.
container-transaction
method
ejb-nameLogEntEJB/ejb-name
method-name*/method-name
   /method
   method
ejb-nameEntUtenteEJB/ejb-name
method-name*/method-name
   /method
  /container-transaction

thanks a lot.

Christian





RE: Transaction problems

2001-07-13 Thread elephantwalker

check out the bad name on your session bean. Looks like that could be an
issue.

container-transaction
method
ejb-nameLogEntEJB/ejb-name !- should be MyEntEJB --
method-name*/method-name
   /method
   method
ejb-nameEntUtenteEJB/ejb-name
method-name*/method-name
   /method
  /container-transaction

regards,

the elephantwalker

.ps We use transaction control with Oracle, and roll backs are only a
problem when there
is a time-out issue. That is, Oracle times out on the transaction before
the server is finished.

If you have nested transactions, are some of them still pending? I mean, a
sfsb is around as long as the session is open or the session times out.
Usually the session time-out is 56 minutes in orion, unless you change it.
Your Oracle time-out is 30 minutes. That mismatch could be the issue.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of J Davis
Sent: Friday, July 13, 2001 7:44 AM
To: Orion-Interest
Subject: RE: Transaction problems


We would also be interested in a solution to this problem as we have
encountered the same thing.  We are using 1.5.2 and Oracle 8.1.6 for our
situation.
We have also run into an issue where if you start a transaction and
inside hit a lot of different data/ejbs the Orion server maxes out it's
CURSOR allocation to oracle.  It creates a new connection and continues
on, but the error is thrown to the logs and can cause some code to skip
steps (due to catching the exception). We were assuming that since the
transaction was still open Orion was not closing any cursors to wait for
a commit, but we don't really know what is going on in the background.

Any ideas?

Greg


-Original Message-
From: Christian Bagnoli [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 13, 2001 6:00 AM
To: Orion-Interest
Subject: Transaction problems


Hi,

we're implementing an entity bean with transactional (container managed)
methods. This bean is accessed by
a session statefull bean. We have transactional problem when a method
fails
(that is throws an EJBException) because orion doesn't rollback the
transaction.
Does anybody figure out how to make orion rollback the transaction?
We have also tried with a session stateless/stateful having the same
problem
.
Also implementing the SessionSycronization interface doesn't trap the
transaction
boundaries.

Our data-source.xml is:

data-source
  class=com.evermind.sql.DriverManagerDataSource
  name=SetmoveDS
  location=jdbc/SetmoveDS
  xa-location=jdbc/xa/MySetmoveDS
  ejb-location=jdbc/myEJBDS
  connection-driver=oracle.jdbc.OracleDriver
  username=test
  password=test
  url=jdbc:oracle:thin:test/test@testsun:1521:test
  inactivity-timeout=30
 /

we use orion 1.5.2.

the ejb-jar.xml is:
.
 session
   display-nameLogEntJAR/display-name
   descriptionLogEntJAR/description
   ejb-nameMyLogEnt/ejb-name
   homesetmove.beans.logica.LogEntHome/home
   remotesetmove.beans.logica.LogEnt/remote
   ejb-classsetmove.beans.logica.LogEntEJB/ejb-class
   session-typeStateful/session-type
   transaction-typeContainer/transaction-type
   ejb-ref
ejb-ref-nameMyEntUtente/ejb-ref-name
ejb-ref-typeEntity/ejb-ref-type
homesetmove.beans.logica.EntUtenteHome/home
remotesetmove.beans.logica.EntUtente/remote
   /ejb-ref
  /session
.
  entity
   display-nameEntUtenteJAR/display-name
   descriptionEntUtenteJAR/description
   ejb-nameMyEntUtente/ejb-name
   homesetmove.beans.logica.EntUtenteHome/home
   remotesetmove.beans.logica.EntUtente/remote
   ejb-classsetmove.beans.logica.EntUtenteEJB/ejb-class
   persistence-typeBean/persistence-type
   prim-key-classjava.lang.String/prim-key-class
   reentrantfalse/reentrant
   resource-ref
descriptiondescription/description
res-ref-namejdbc/SetmoveDS/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
   /resource-ref
  /entity
.
container-transaction
method
ejb-nameLogEntEJB/ejb-name
method-name*/method-name
   /method
   method
ejb-nameEntUtenteEJB/ejb-name
method-name*/method-name
   /method
  /container-transaction

thanks a lot.

Christian










Re: Transaction problems...

2000-08-22 Thread Chris Miller

I'm just guessing, but have you tried setting exclusive-write-access="false"
in your orion-ejb-jar.xml file? It sounds like Orion is doing some
optimisation to speed things up because it thinks it has exclusive write
access to the database - but your triggers are going behind Orion's back
without it realising. Turning this off might force Orion to call the
ejbLoad.

See \orion\docs\orion-ejb-jar.xml.html for more info.

Worth a try anyway...


- Original Message -
From: [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Tuesday, August 22, 2000 2:04 PM
Subject: Transaction problems...



 We have been using transactions successfully for a while nowor so we
 thought.

 Here is the scenario.  We have a series of registration pages on our site.
 We gather all the information we need, and at the end
 we create a stateless session bean passing it all the information we need.
 In this session bean, we have seven tables that get
 modified by calling the create method of seven different entity beans.  We
 wrap the whole series of method calls in a usertransaction
 similar to the following:
 code
   InitialContext context = null;
   TransactionManager manager = null;
   context = new InitialContext();
   manager = (TransactionManager)context.lookup
 ("java:comp/UserTransaction");
   manager.begin();
   try {
org = createOrganization();
orgLoc = createOrganizationLocation();
orgUsers = createOrganizationUsers();
orgLocUsers = createOrgLocationUsers();
createEquipmentTypeOrganization();
regStatHist = createRegistrationStatusHist();
notifyUser();

   }
   catch(RegistrationException re) {
manager.rollback();
throw re;
   }
   manager.commit();
 /code

 From the surface, this looks to work normally.  If an excpetion is thrown
 in any method, the entire transaction gets rolled back.
 however, our problem lies within the order that Orion calls the methods on
 the EJB.  When the above code is *NOT* wrapped within
 a transaction, only the ejbCreate of each entity bean gets called.
Nothing
 else.  However, wrapped in a transaction like the
 above, immediately after the ejbCreate method is called, the ejbStore
 method is called.  Now here is the big reason this is a bad thing.
 All of our tables have triggers on them that set two of the columns.
These
 triggers are set in the database on the insertion of a row.  But when
 the ejbStore method is called, it does not sync itself back up with the
 database to get the newly created values in these columns, and does an
 update
 with the locally held values, which happen o be null.  It seems that
 ejbLoad should be called *before* ejbStore gets called.

 Can someone tell me what I am missing here?  In order to get around this
 problem, we have resorted to hardcoding the proper trigger generated
 values into the EJB, but that is a very unflexible solution.  Any help
 would be greatly appreciated.


 James Birchfield

 Ironmax
 a better way to buy, sell and rent construction equipment
 5 Corporate Center
 9960 Corporate Campus Drive,
 Suite 2000
 Louisville, KY 40223








Re: Transaction problems...

2000-08-22 Thread jbirchfield


Thanks for the tip.  Unfortunately, this seems to have no affect.  I have
tried to set the exclusive-write-access to false, and have played with
different isolation levels as well.  I will keep plugging away i guess.

Thanks again!


James Birchfield

Ironmax
a better way to buy, sell and rent construction equipment
5 Corporate Center
9960 Corporate Campus Drive,
Suite 2000
Louisville, KY 40223


|+---
||  "Chris   |
||  Miller"  |
||  kiwi@vardus.|
||  co.uk   |
||   |
||  08/22/00 |
||  10:32 AM |
||   |
|+---
  
-|
  |
 |
  |   To: [EMAIL PROTECTED], "Orion-Interest" 
[EMAIL PROTECTED]  |
  |   cc:  
 |
  |       Subject: Re: Transaction problems... 
 |
  
-|



I'm just guessing, but have you tried setting exclusive-write-access
="false"
in your orion-ejb-jar.xml file? It sounds like Orion is doing some
optimisation to speed things up because it thinks it has exclusive write
access to the database - but your triggers are going behind Orion's back
without it realising. Turning this off might force Orion to call the
ejbLoad.

See \orion\docs\orion-ejb-jar.xml.html for more info.

Worth a try anyway...


- Original Message -
From: [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Tuesday, August 22, 2000 2:04 PM
Subject: Transaction problems...



 We have been using transactions successfully for a while nowor so we
 thought.

 Here is the scenario.  We have a series of registration pages on our
site.
 We gather all the information we need, and at the end
 we create a stateless session bean passing it all the information we
need.
 In this session bean, we have seven tables that get
 modified by calling the create method of seven different entity beans.
We
 wrap the whole series of method calls in a usertransaction
 similar to the following:
 code
   InitialContext context = null;
   TransactionManager manager = null;
   context = new InitialContext();
   manager = (TransactionManager)context.lookup
 ("java:comp/UserTransaction");
   manager.begin();
   try {
org = createOrganization();
orgLoc = createOrganizationLocation();
orgUsers = createOrganizationUsers();
orgLocUsers = createOrgLocationUsers();
createEquipmentTypeOrganization();
regStatHist = createRegistrationStatusHist();
notifyUser();

   }
   catch(RegistrationException re) {
manager.rollback();
throw re;
   }
   manager.commit();
 /code

 From the surface, this looks to work normally.  If an excpetion is thrown
 in any method, the entire transaction gets rolled back.
 however, our problem lies within the order that Orion calls the methods
on
 the EJB.  When the above code is *NOT* wrapped within
 a transaction, only the ejbCreate of each entity bean gets called.
Nothing
 else.  However, wrapped in a transaction like the
 above, immediately after the ejbCreate method is called, the ejbStore
 method is called.  Now here is the big reason this is a bad thing.
 All of our tables have triggers on them that set two of the columns.
These
 triggers are set in the database on the insertion of a row.  But when
 the ejbStore method is called, it does not sync itself back up with the
 database to get the newly created values in these columns, and does an
 update
 with the locally held values, which happen o be null.  It seems that
 ejbLoad should be called *before* ejbStore gets called.

 Can someone tell me what I am missing here?  In order to get around this
 problem, we have resorted to hardcoding the proper trigger generated
 values into the EJB, but that is a very unflexible solution.  Any help
 would be greatly appreciated.


 James Birchfield

 Ironmax
 a better way to buy, sell and rent construction equipment
 5 Corporate Center
 9960 Corporate Campus Drive,
 Suite 2000
 Louisville, KY 40223