Note: some JPA implementations are clever enough to just do nothing if the persist is followed directly by remove BusinessObjectLock is a persistent objectīusinessObjectLock lock = new BusinessObjectLock(objId) persist (lock ) // Note: some JPA implementations are clever enough to just do nothing if the persist is followed directly by remove BusinessObjectLock is a persistent objectīusinessObjectLock lock = new BusinessObjectLock (objId ) Įm. If the entire transaction rolls-back, both the insert and the delete are rolled back and nothing is left behind.ĮntityManager em =.If the entire transaction commits, both the insert and the delete are committed and nothing is left behind.If the transaction first inserts and immediately thereafter deletes the row, we can ensure that the locks are not “lost”: Even if tx-A deletes the same row before it terminates. When set at “READ COMMITED”, any other transaction must not know anything about what tx-A is doing until the transaction is finished. When one transaction (tx-A) inserts a row in this table with a specific id (the business object ID), other transactions trying to insert a row with the same id must wait, until tx-A either commits or rolls-back. Locked_ts TIMESTAMP NOT NULL, CONSTRAINT pk_businessobjectlock PRIMARY KEY (uuid ), CONSTRAINT id_businessobjectlock UNIQUE (id ) ) ĬONSTRAINT pk_businessobjectlock PRIMARY KEY (uuid),ĬONSTRAINT id_businessobjectlock UNIQUE (id) “BondBO” for the Bond Business Object) and the object’s unique ID (e.g, the Bond’s ISIN): “BondBO:DK0015966592” (Note that DK0015966592 is not actually an ISIN of a Bond).īelow is DDL for a business object lock table: A business object is identified by the name of the entity (e.g. In this sample we create a business object lock – an exclusive lock that can be put on any business object.
The transactions need not be JEE CMT or anything fancy just plain old JDBC connections with autocommit=false can do the trick. So a mechanism was needed to ensure, that a specific document was not handled by more than one transaction at a time.Īn “exclusive lock” was needed, and it had to work with documents that were not registered in the system yet.Īll you need is a table with a unique index and transactions with isolation level “READ COMMITTED” or higher. The same document could enter the system in different versions at any point in time there was no ordering etc. If the document had a newer timestamp than the registered, it would be updated. If the document were not registered, it would be created. Incoming documents were complete in that it would contain a “recent” copy of all document information. Three application servers were dedicated to the task of handling the incoming documents.Įach document had a unique ID that was generated from certain key information contained within the document. Each document had to be transformed and processed and corresponding database tables updated. I saw this feature implemented the first time in a system that received about a million XML documents over a couple of hours. The technique can be used to serialize access to a specific entity or object graph in a system, where several application servers share a common database.
It works with PostgreSQL, DB2, Oracle and Apache Derby (JavaDB) and possibly others. The technique works with all major databases, and should work with any database that has a reasonable implementation of the isolation level “READ COMMITTED”. In this article I will describe a simple technique that enables you to implement an “exclusive lock” in a distributed, even clustered, environment.
0 kommentar(er)
