About lock

1-10 of 173Refresh
Manual
258

Locking in JPA

JPA 2 supports both optimistic locking and pessimistic locking. Locking is essential to avoid update collisions resulting from simultaneous updates to the same data by two concurrent users. Locking in ObjectDB (and in JPA) is always at the database object level, i.e. each database object is locked
JPA Doc
63

lock(entity, lockMode, properties)

Method javax.persistence.EntityManager void lock(   Object entity,   LockModeType lockMode,   Map properties ) Lock an entity instance that is contained in the persistence context with the specified lock mode type and with specified properties. If a pessimistic lock mode type
JPA Doc
62

lock(entity, lockMode)

Method javax.persistence.EntityManager void lock(   Object entity,   LockModeType lockMode ) Lock an entity instance that is contained in the persistence context with the specified lock mode type. If a pessimistic lock mode type is specified and the entity contains a version attribute
Manual
39

Setting and Tuning of JPA Queries

. Therefore, when performance is important, this issue has to be considered. Lock Mode (setLockMode) ObjectDB uses automatic optimistic locking to prevent concurrent changes to entity objects by multiple users. JPA 2 adds support for pessimistic locking. The setLockMode method sets a lock mode
JPA Doc
33

javax.persistence.EntityManager

 primaryKey, LockModeType lockMode) Find by primary key and lock. Find by primary key and lock. Search for an entity of the specified class and primary key and lock it with respect to the specified lock type. If the entity instance is contained in the persistence context, it is returned from
Result
28

ObjectDB Object Database Features

. Support of efficient real multithreading. Support of efficient real multiprocessing. Locking Automatic object versioning (can be injected to a @Version field). Optimistic locking (always active). Implicit pessimistic locking (JDO). Explicit pessimistic locking (JPA 2). Always Object Level locking
Manual
28

Database Management Settings

="." mode="write" />   <locking version-check="true" /> locking> element <locking version-check="true" /> The version-check attribute of the <locking> element specifies
Forum
22

Pessimistic Lock Timeouts setting

Hi,   I realise that JPA2 doesn't necessarily define a standard API way for Lock Timeouts. However, there is a standardised query 'hint' that can be setup to make the underlying DB lock a record for a specific time. The hint property is: "javax.persistence.lock.timeout" I have a situation
Forum
22

locks on pure query activities

that are just doing simple queries (just selects, no update or delete ...) show locks like these (question is: why there are locks and how could we get rid of that):   log1: "qtp1523553211-271" #271 prio ... ) - waiting to lock <0x0000000202239c10> (a com.objectdb.o.LFL) at com.objectdb.o.PAG
Forum
21

Pessimestic Locking doesn't release when application unexpectedly terminates.

. Our approach to this was to use Objectdb's pessimestic locking. This seems to work, but if the owner of the current pessimestic lock abruptly quits without releasing the lock it doesn't get released.    Is there anyway the server can detect that a client (lock owner is no longer connected