Perform database operation outside Seam tranaction

[rnicholson10]

I have a need to be able to perform a database operation outside of the transaction managed by Seam.

I'd like to know if this is possible. We have several thrid party db's which we interact with which we end up locking.

We only have a few actions which require this functionality, but these actions would still require transaction management as well as parts which are not managed.

Currently our solution is a fragile hack where we sub commit within the action

          Transaction.instance().commit();
          Transaction.instance().begin();

Unfortunately this commits everything.

Is there a better way to do this?

[asookazian]

We have several thrid party db's which we interact with which we end up locking.

What do you mean exactly by this?  table locks, row locks, page locks?

Generally speaking it's not a good idea to run your app in AUTOCOMMIT without transactions.  With EJB3 and Seam, you can use CMT (declarative) or BMT (programmatic for fine-grained control).

Unfortunately this commits everything.

what does that mean exactly?

You need to be as specific as possible (typically with code snippets and config files as required) to get as much help as possible...

[rnicholson10]

It's row locking we have a issue with.

I agree, AUTOCOMMIT is not what I'm looking for either.

Ok, let me break this down with an example:

     public void myAction()
     {
          for (int i = 0; i < 1000000; i++)
          {
               updateMainDb(i);
               updatePrivateDb(i);
          }
     }

The method updateMainDb() will run a million times and when the action is finished Seam will commit all the changes. In this example updatePrivateDb() will also be part of this transaction, I don't want this. The method updatePrivateDb() should be called outside the main Seam transaction, so it can be committed on each call (so we have no locking). We really don't care about the state of the privateDb if Seam rolls back it's transactions, it should not be rolled back no matter what happens.

I know this is a very unusual use case. I don't like our current solution as the atomicity of the MainDb is affected by a requirement of privateDb.

I hope this is a little clearer.

Thanks

[niox.nikospara.yahoo.com]

Hello,

In your last example, updatePrivateDb() could be a method of a session EJB, annotated with @TransactionAttribute(REQUIRES_NEW). The container will suspend the current transaction (the one initiated by Seam) and run updatePrivateDb() in a new one, that commits when updatePrivateDb() returns.

[jeanluc]

Also consider @TransactionAttribute(NOT_SUPPORTED) if you have a single statement in updatePrivateDb()

[rnicholson10]

Great! Thanks for both solutions!