Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Examples/JPA/Locking"
m |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==How to Use EclipseLink Locking== | ==How to Use EclipseLink Locking== | ||
You can configure a descriptor with a locking policy that prevents one user writing over another user's work. | You can configure a descriptor with a locking policy that prevents one user writing over another user's work. | ||
| − | *[[#Pessemistic Locking| | + | *[[#Pessemistic Locking|Pessimistic Locking]] |
*[[#Optimistic Locking|Optimistic Locking]] | *[[#Optimistic Locking|Optimistic Locking]] | ||
| − | + | ==Pessimistic Locking == | |
| − | == | + | |
With pessimistic locking, the first user who accesses the data with the purpose of updating it locks the data until completing the update. The disadvantage of this approach is that it may lead to reduced concurrency and deadlocks. | With pessimistic locking, the first user who accesses the data with the purpose of updating it locks the data until completing the update. The disadvantage of this approach is that it may lead to reduced concurrency and deadlocks. | ||
See, [[EclipseLink/Examples/JPA/PessimisticLocking|PessimisticLocking]] | See, [[EclipseLink/Examples/JPA/PessimisticLocking|PessimisticLocking]] | ||
| − | |||
==Optimistic Locking== | ==Optimistic Locking== | ||
| Line 16: | Line 14: | ||
By default, EclipseLink persistence provider assumes that the application is responsible for data consistency. | By default, EclipseLink persistence provider assumes that the application is responsible for data consistency. | ||
| + | EclipseLink also supports several extended locking policies and options in addition to JPA Version locking, see [[Using_EclipseLink_JPA_Extensions_(ELUG)#Using_EclipseLink_JPA_Extensions_for_Optimistic_Locking|Using EclipseLink JPA Extensions for Optimistic Locking]]. | ||
===Version Locking=== | ===Version Locking=== | ||
| Line 25: | Line 24: | ||
* '''VersionLockingPolicy''': requires a numeric version field; EclipseLink updates the version field by incrementing its value by one. | * '''VersionLockingPolicy''': requires a numeric version field; EclipseLink updates the version field by incrementing its value by one. | ||
* '''TimestampLockingPolicy''': requires a timestamp version field; EclipseLink updates the version field by inserting a new timestamp (this policy can be configured to get the time from the data source or locally; by default, the policy gets the time from the data source). | * '''TimestampLockingPolicy''': requires a timestamp version field; EclipseLink updates the version field by inserting a new timestamp (this policy can be configured to get the time from the data source or locally; by default, the policy gets the time from the data source). | ||
| − | |||
'''''Optimistic Version Locking Example''''' | '''''Optimistic Version Locking Example''''' | ||
| − | + | <source lang="java"> | |
| − | <source="java"> | + | |
@Entity | @Entity | ||
| − | public class | + | public class Employee implements Serializable { |
... | ... | ||
@Version | @Version | ||
| − | @Column(name=" | + | @Column(name="VERSION") |
| − | protected int | + | protected int getVersion() { |
| − | return | + | return version; |
} | } | ||
... | ... | ||
| − | |||
</source> | </source> | ||
The field or property type must either be a numeric type (such as Number, long, int, BigDecimal, and so on), or a '''java.sql.Timestamp'''. We recommend using a numeric type. | The field or property type must either be a numeric type (such as Number, long, int, BigDecimal, and so on), or a '''java.sql.Timestamp'''. We recommend using a numeric type. | ||
| − | [[Category:EclipseLink/Example/JPA | Locking]] | + | [[Category:EclipseLink/Example/JPA|Locking]] |
Latest revision as of 07:16, 30 April 2011
Contents
How to Use EclipseLink Locking
You can configure a descriptor with a locking policy that prevents one user writing over another user's work.
Pessimistic Locking
With pessimistic locking, the first user who accesses the data with the purpose of updating it locks the data until completing the update. The disadvantage of this approach is that it may lead to reduced concurrency and deadlocks.
See, PessimisticLocking
Optimistic Locking
With optimistic locking, all users have read access to the data. When a user attempts to write a change, the application checks to ensure the data has not changed since the user read the data.
By default, EclipseLink persistence provider assumes that the application is responsible for data consistency.
EclipseLink also supports several extended locking policies and options in addition to JPA Version locking, see Using EclipseLink JPA Extensions for Optimistic Locking.
Version Locking
Optimistic version locking policies enforce optimistic locking by using a version field (also known as a write-lock field) that you provide in the reference class that EclipseLink updates each time an object change is committed.
Use the @Version annotation to enable the JPA-managed optimistic locking by specifying the version field or property of an entity class that serves as its optimistic lock value (recommended).
EclipseLink provides the following version-based optimistic locking policies:
- VersionLockingPolicy: requires a numeric version field; EclipseLink updates the version field by incrementing its value by one.
- TimestampLockingPolicy: requires a timestamp version field; EclipseLink updates the version field by inserting a new timestamp (this policy can be configured to get the time from the data source or locally; by default, the policy gets the time from the data source).
Optimistic Version Locking Example
@Entity public class Employee implements Serializable { ... @Version @Column(name="VERSION") protected int getVersion() { return version; } ...
The field or property type must either be a numeric type (such as Number, long, int, BigDecimal, and so on), or a java.sql.Timestamp. We recommend using a numeric type.