Details | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
33 | PointedEar | 1 | //$Id: LockModeType.java 11282 2007-03-14 22:05:59Z epbernard $ |
2 | package javax.persistence; |
||
3 | |||
4 | /** |
||
5 | * Lock modes that can be specified by means of the EntityManager.lock() method. |
||
6 | * |
||
7 | * The semantics of requesting locks of type LockModeType.READ and LockModeType.WRITE are t |
||
8 | * he following. |
||
9 | * |
||
10 | * If transaction T1 calls lock(entity, LockModeType.READ) on a versioned object, the entity |
||
11 | * manager must ensure that neither of the following phenomena can occur: |
||
12 | * |
||
13 | * * P1 (Dirty read): Transaction T1 modifies a row. Another transaction T2 then reads |
||
14 | * that row and obtains the modified value, before T1 has committed or rolled back. |
||
15 | * Transaction T2 eventually commits successfully; it does not matter whether T1 commits or rolls |
||
16 | * back and whether it does so before or after T2 commits. |
||
17 | * |
||
18 | * * P2 (Non-repeatable read): Transaction T1 reads a row. Another transaction T2 then modifies |
||
19 | * or deletes that row, before T1 has committed. Both transactions eventually commit successfully. |
||
20 | * |
||
21 | * Lock modes must always prevent the phenomena P1 and P2. |
||
22 | * In addition, calling lock(entity, LockModeType.WRITE) on a versioned object, |
||
23 | * will also force an update (increment) to the entity's version column. |
||
24 | * |
||
25 | * The persistence implementation is not required to support calling EntityManager.lock() |
||
26 | * on a non-versioned object. When it cannot support a such lock call, it must |
||
27 | * throw the PersistenceException. |
||
28 | * |
||
29 | * @author Emmanuel Bernard |
||
30 | */ |
||
31 | public enum LockModeType { |
||
32 | /** |
||
33 | * Read lock |
||
34 | */ |
||
35 | READ, |
||
36 | /** |
||
37 | * Write lock |
||
38 | */ |
||
39 | WRITE |
||
40 | } |