Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you use JTA transactions than the transaction boundary spreads from method's begin to its end. </p> <p>Therefore, changes made in an <strong>active</strong> transaction T1 can't be seen in transaction T2. If you think about it, it's quite reasonable. Assume that T2 could operate on data which was changed by T1 but <strong>not committed</strong>. Upon T1 rollback, every changes made to the entities in T1 must be invalidated. You've ended in a situation in which T2 operated on invalid data.</p> <p>That's why you won't see 'Joe 1' (this value is changed only in T1) from any transaction other than T1. You can only see 'Joe 2' when methods ends (T1 commits).</p> <p>The <a href="http://download.oracle.com/javaee/6/api/javax/persistence/EntityManager.html#flush%28%29" rel="nofollow">EntityManager#flush()</a> synchronizes the data with the underlying database but <strong>does not commit it</strong>. For more detailed information you can see this thread: <a href="http://www.java.net/node/665442#comment-678155" rel="nofollow">http://www.java.net/node/665442#comment-678155</a></p> <p>I can see three solutions in this case:</p> <ol> <li><p>Optimistic locking could save you from situations in which two transactions T1 and T2 change the same data (the same entity). In case you have no locking, only the last committed transaction changes will be reflected in the database (so you've changes made by the former transaction are lost). With locking, you will get an Exception in the last committed transaction, so no data will be lost.</p></li> <li><p>Pessimistic locking could lock the data for the time of modification. In this case, your transaction T2 would not operate on the data until T1 finishes.</p></li> <li><p>At last - the most simple situation is (if possible) just to separate your method to smaller chunks.</p></li> </ol> <p>HTH.</p>
    singulars
    1. This table or related slice is empty.
    1. POJPA entity updated only after method is done
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USPiotr Nowicki
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POJPA entity updated only after method is done
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'm not using JTA transaction, or am I? The only JTA related code is in my persistence.xml: <persistence-unit name="com.bla.PU" transaction-type="JTA">. I am not starting/committing any transaction on my own. The methods described in the OP are not surrounded by a transaction.
      singulars
      1. PO
      1. USBigJ
    2. COThe relevant part you shown is the JTA usage declaration. Because you use the JTA you don't have any start/commit code for transactions. If you would use RESOURCE_LOCAL transaction-type than you would need to set the boundaries of the transaction by explicitly using start/commit. As said, by default JTA transaction starts at the method begin and ends upon commit.
      singulars
      1. PO
      1. USPiotr Nowicki
    3. COThank you :) If anyone wants to add information go ahead. Meanwhile I will set this as the answer.
      singulars
      1. PO
      1. USBigJ
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload