You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Andreas Bohnert <ab...@online.de> on 2004/04/22 12:36:07 UTC

transactions in a managed environment: help needed!

hello everybody,

we do a jboss project and we use the persistence broker only.
therefore we use the PersistenceBrokerFactorySyncImpl, which is 
recommend to use with managed environments and pb only.
we don't use entity beans. we have a stateless OjbSessionBean, which is 
called for any db activities.


here comes the problem:

if an error occurs in a sequence of n inserts/updates/deletes I want to 
rollback the whole thing. When I have a look at my spy.log, there is 
always a commit at the end of the log (and no rollback), even if ojb 
throws an exception because of that error.
because it's not allowed to use broker.beginTransaction in my code, I 
can't to anything to mark/abort/commit my transaction.

I had a look at the faq, so I know I could do it like that:

Transaction tx = odmg.newTransaction(); tx.begin();
PersistenceBroker broker = ((HasBroker) tx).getBroker();
....
broker.dothisanddothat();
..
tx.commit();

my questions are:
1.) is this the recommend way, if I want to use transactions with my pk?
    if yes: can I still use PersistenceBrokerFactorySyncImpl or do i 
have to switch back to PersistenceBrokerFactoryDefaultImpl.(because of odmg)

2.) how do I have to set the the xdoclet tag 'transaction' to use normal 
broker.beginTransaction() and do not let jboss do the transactions?
    are there any drawbacks if I do so?

thanks for any advice!!
andreas  








---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


Re: transactions in a managed environment: help needed!

Posted by Armin Waibel <ar...@apache.org>.
Andreas Bohnert wrote:
> thanks very much, armin!
> 
> I throwed just an Exception not an EJBException, so in case of a non 
> SQLException the container didn't recognize the error.
> Now I just throw the EJBException and the rollback takes place. cool!
> 
> Do you know why the container (or transaction manager) don't handle 
> normal Exceptions?
>

sorry no, I suppose that it's specified in the spec.
To confirm my suppose, here is a snip of EJBException javadoc:
"The EJBException exception is thrown by an enterprise Bean instance to 
its container to report that the invoked business method or callback 
method could not be completed because of an unexpected error (e.g. the 
instance failed to open a database connection)."

regards,
Armin

> regards
> andreas
> 
> Armin Waibel wrote:
> 
>> Hi Andreas,
>>
>> Andreas Bohnert wrote:
>>
>>> hello everybody,
>>>
>>> we do a jboss project and we use the persistence broker only.
>>> therefore we use the PersistenceBrokerFactorySyncImpl, which is 
>>> recommend to use with managed environments and pb only.
>>> we don't use entity beans. we have a stateless OjbSessionBean, which 
>>> is called for any db activities.
>>>
>>>
>>> here comes the problem:
>>>
>>> if an error occurs in a sequence of n inserts/updates/deletes I want 
>>> to rollback the whole thing. When I have a look at my spy.log, there 
>>> is always a commit at the end of the log (and no rollback), even if 
>>> ojb throws an exception because of that error.
>>> because it's not allowed to use broker.beginTransaction in my code, I 
>>> can't to anything to mark/abort/commit my transaction.
>>>
>>> I had a look at the faq, so I know I could do it like that:
>>>
>>> Transaction tx = odmg.newTransaction(); tx.begin();
>>> PersistenceBroker broker = ((HasBroker) tx).getBroker();
>>> ....
>>> broker.dothisanddothat();
>>> ..
>>> tx.commit();
>>>
>>
>> this is only valid for non-managed environments using ODMG. In managed 
>> environments you can only use "non-tx" methods of the ODMG-transaction 
>> instance, e.g. locking handling.
>>
>>> my questions are:
>>> 1.) is this the recommend way, if I want to use transactions with my pk?
>>
>>
>>
>> no, see above
>>
>>>    if yes: can I still use PersistenceBrokerFactorySyncImpl or do i 
>>> have to switch back to PersistenceBrokerFactoryDefaultImpl.(because 
>>> of odmg)
>>>
>>
>> in that case you have to use the default PBF implementation
>>
>>> 2.) how do I have to set the the xdoclet tag 'transaction' to use 
>>> normal broker.beginTransaction() and do not let jboss do the 
>>> transactions?
>>>    are there any drawbacks if I do so?
>>>
>>
>> sorry I don't have much experience with the xdoclet module. To prevent 
>> container-tx demarcation set transaction attribute to 'none' (I 
>> suppose so).
>>
>> In managed environments it's not possible to use the PB-tx 
>> demarcation. The transaction demarcation and handling was delegated to 
>> the JTA/JTS of the container.
>> If you want to do bean-managed tx-demarcation use JTA UserTransaction 
>> and set transaction attribute for your bean in deployment descriptor 
>> to none.
>> Then you can do:
>>
>> UserTransaction tx = context.lookup(..jndi-path for UserTransaction..);
>> tx.begin()
>> // after begin lookup the PB instance
>> PersistenceBroker pb = PersistenceBrokerFactory....
>> // or if you bound PBF into JNDI, do a lookup
>> ...
>> // perform your work
>> tx.commit()
>> // or rollback
>>
>> But in most cases it's not necessary to use bm-tx.
>>
>> > if an error occurs in a sequence of n inserts/updates/deletes I want
>> > to rollback the whole thing
>>
>> if you detect an error in your bean you have two possibilities:
>> - set the EJBContext to rollback only
>> ctx.setRollbackOnly();
>> - throw an EJBException
>>
>> I recommend to throw an EJBException, because it seems that 
>> setRollbackOnly prevent the container to do the callback on the 
>> Synchronization interface used by PersistenceBrokerFactorySyncImpl and 
>> the rollback will not by recognised by OJB.
>>
>> If the error was caused by the DB (SQLException), then it should be 
>> also possible to ignore the exception, because the used managed 
>> connection should inform the container from that failure and the 
>> container should do a rollback whether or not you throw an exception 
>> within your bean.
>>
>> regards,
>> Armin
>>
>>> thanks for any advice!!
>>> andreas
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


Re: transactions in a managed environment: help needed!

Posted by Andreas Bohnert <ab...@online.de>.
thanks very much, armin!

I throwed just an Exception not an EJBException, so in case of a non 
SQLException the container didn't recognize the error.
Now I just throw the EJBException and the rollback takes place. cool!

Do you know why the container (or transaction manager) don't handle 
normal Exceptions?

regards
andreas

Armin Waibel wrote:

> Hi Andreas,
>
> Andreas Bohnert wrote:
>
>> hello everybody,
>>
>> we do a jboss project and we use the persistence broker only.
>> therefore we use the PersistenceBrokerFactorySyncImpl, which is 
>> recommend to use with managed environments and pb only.
>> we don't use entity beans. we have a stateless OjbSessionBean, which 
>> is called for any db activities.
>>
>>
>> here comes the problem:
>>
>> if an error occurs in a sequence of n inserts/updates/deletes I want 
>> to rollback the whole thing. When I have a look at my spy.log, there 
>> is always a commit at the end of the log (and no rollback), even if 
>> ojb throws an exception because of that error.
>> because it's not allowed to use broker.beginTransaction in my code, I 
>> can't to anything to mark/abort/commit my transaction.
>>
>> I had a look at the faq, so I know I could do it like that:
>>
>> Transaction tx = odmg.newTransaction(); tx.begin();
>> PersistenceBroker broker = ((HasBroker) tx).getBroker();
>> ....
>> broker.dothisanddothat();
>> ..
>> tx.commit();
>>
>
> this is only valid for non-managed environments using ODMG. In managed 
> environments you can only use "non-tx" methods of the ODMG-transaction 
> instance, e.g. locking handling.
>
>> my questions are:
>> 1.) is this the recommend way, if I want to use transactions with my pk?
>
>
> no, see above
>
>>    if yes: can I still use PersistenceBrokerFactorySyncImpl or do i 
>> have to switch back to PersistenceBrokerFactoryDefaultImpl.(because 
>> of odmg)
>>
>
> in that case you have to use the default PBF implementation
>
>> 2.) how do I have to set the the xdoclet tag 'transaction' to use 
>> normal broker.beginTransaction() and do not let jboss do the 
>> transactions?
>>    are there any drawbacks if I do so?
>>
>
> sorry I don't have much experience with the xdoclet module. To prevent 
> container-tx demarcation set transaction attribute to 'none' (I 
> suppose so).
>
> In managed environments it's not possible to use the PB-tx 
> demarcation. The transaction demarcation and handling was delegated to 
> the JTA/JTS of the container.
> If you want to do bean-managed tx-demarcation use JTA UserTransaction 
> and set transaction attribute for your bean in deployment descriptor 
> to none.
> Then you can do:
>
> UserTransaction tx = context.lookup(..jndi-path for UserTransaction..);
> tx.begin()
> // after begin lookup the PB instance
> PersistenceBroker pb = PersistenceBrokerFactory....
> // or if you bound PBF into JNDI, do a lookup
> ...
> // perform your work
> tx.commit()
> // or rollback
>
> But in most cases it's not necessary to use bm-tx.
>
> > if an error occurs in a sequence of n inserts/updates/deletes I want
> > to rollback the whole thing
>
> if you detect an error in your bean you have two possibilities:
> - set the EJBContext to rollback only
> ctx.setRollbackOnly();
> - throw an EJBException
>
> I recommend to throw an EJBException, because it seems that 
> setRollbackOnly prevent the container to do the callback on the 
> Synchronization interface used by PersistenceBrokerFactorySyncImpl and 
> the rollback will not by recognised by OJB.
>
> If the error was caused by the DB (SQLException), then it should be 
> also possible to ignore the exception, because the used managed 
> connection should inform the container from that failure and the 
> container should do a rollback whether or not you throw an exception 
> within your bean.
>
> regards,
> Armin
>
>> thanks for any advice!!
>> andreas
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


Re: transactions in a managed environment: help needed!

Posted by Armin Waibel <ar...@apache.org>.
Hi Andreas,

Andreas Bohnert wrote:

> hello everybody,
> 
> we do a jboss project and we use the persistence broker only.
> therefore we use the PersistenceBrokerFactorySyncImpl, which is 
> recommend to use with managed environments and pb only.
> we don't use entity beans. we have a stateless OjbSessionBean, which is 
> called for any db activities.
> 
> 
> here comes the problem:
> 
> if an error occurs in a sequence of n inserts/updates/deletes I want to 
> rollback the whole thing. When I have a look at my spy.log, there is 
> always a commit at the end of the log (and no rollback), even if ojb 
> throws an exception because of that error.
> because it's not allowed to use broker.beginTransaction in my code, I 
> can't to anything to mark/abort/commit my transaction.
> 
> I had a look at the faq, so I know I could do it like that:
> 
> Transaction tx = odmg.newTransaction(); tx.begin();
> PersistenceBroker broker = ((HasBroker) tx).getBroker();
> ....
> broker.dothisanddothat();
> ..
> tx.commit();
> 

this is only valid for non-managed environments using ODMG. In managed 
environments you can only use "non-tx" methods of the ODMG-transaction 
instance, e.g. locking handling.

> my questions are:
> 1.) is this the recommend way, if I want to use transactions with my pk?

no, see above

>    if yes: can I still use PersistenceBrokerFactorySyncImpl or do i have 
> to switch back to PersistenceBrokerFactoryDefaultImpl.(because of odmg)
> 

in that case you have to use the default PBF implementation

> 2.) how do I have to set the the xdoclet tag 'transaction' to use normal 
> broker.beginTransaction() and do not let jboss do the transactions?
>    are there any drawbacks if I do so?
> 

sorry I don't have much experience with the xdoclet module. To prevent 
container-tx demarcation set transaction attribute to 'none' (I suppose so).

In managed environments it's not possible to use the PB-tx demarcation. 
The transaction demarcation and handling was delegated to the JTA/JTS of 
the container.
If you want to do bean-managed tx-demarcation use JTA UserTransaction 
and set transaction attribute for your bean in deployment descriptor to 
none.
Then you can do:

UserTransaction tx = context.lookup(..jndi-path for UserTransaction..);
tx.begin()
// after begin lookup the PB instance
PersistenceBroker pb = PersistenceBrokerFactory....
// or if you bound PBF into JNDI, do a lookup
...
// perform your work
tx.commit()
// or rollback

But in most cases it's not necessary to use bm-tx.

 > if an error occurs in a sequence of n inserts/updates/deletes I want
 > to rollback the whole thing

if you detect an error in your bean you have two possibilities:
- set the EJBContext to rollback only
ctx.setRollbackOnly();
- throw an EJBException

I recommend to throw an EJBException, because it seems that 
setRollbackOnly prevent the container to do the callback on the 
Synchronization interface used by PersistenceBrokerFactorySyncImpl and 
the rollback will not by recognised by OJB.

If the error was caused by the DB (SQLException), then it should be also 
possible to ignore the exception, because the used managed connection 
should inform the container from that failure and the container should 
do a rollback whether or not you throw an exception within your bean.

regards,
Armin

> thanks for any advice!!
> andreas 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org