I've been searching about the possibility of propagate a JTA transaction from Java code to Oracle stored procedures and found nothing really relevant. I'm asking this because a coworker is working with this and told me that it worked for him.
What I'm wondering is a situation where some operation has not been flushed because the transaction is still opened and subsequently a stored procedure is called (this procedure doesn't control it's own transaction), will the stored procedure be able to see the pendent operation in the Persistence Context? In other words, will the Persistence Context synchronize somehow with the transactional memory of the underneath database?
I'm studying for the Oracle JPA exam and such thing is not described in the book I'm reading. However I've read in some websites that I googled and people say that such transaction propagation works because there are a integration between JTA and database transactions in certain JDBC drivers (I just can't imagine how it could work, are the transaction manager aware of database transactions??).
Calling a stored procedure is not much different than executing any other SQL statement. It will execute in the current transaction, any database changes you have done in the transaction will be visible to the stored procedure.
With JPA, you can also have un-flushed in-memory changes, in this case you may need to call flush() on your EntityManager to write the changes to the database. Also ensure you use the same entity manager (or its connection) to execute the stored procedure. If you use a different em or JDBC connection it will most likely be in a different transaction context.
I've one more question that a friend of mine said and I couldn't test it yet, maybe you help me one more time. Once I called flush in order to send the in-memory changes I did to the database, it will be already committed or it will become part of the transaction that the stored procedure joined?
Thanks in advance!
Joined: Oct 01, 2007
flush() does not commit the transaction, it only writes the changes to the database in the active transaction. The changes are not committed until you commit the transaction.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Transaction propagation and Persistence Context synchronization with Oracle Stored Procedures