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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
