Transactions and read/write property

[calle]

Hi
I have a scenario where nodeService.getProperty() and nodeService.setProperty() for the same property on the same node is executed inside a RetryingTransactionCallback:

final RetryingTransactionHelper trxHelper = transactionService.getRetryingTransactionHelper();
return trxHelper.doInTransaction(new RetryingTransactionCallback<NodeRef>() {
   public NodeRef execute() throws Throwable {
      final int v = nodeService.getProperty(nodeRef, qName);
      nodeService.setProperty(nodeRef, qName, v + 1);
   }
}
‍‍‍‍‍‍‍‍‍

In this example the property is a simple value that is incremented by one.

Now, if one client is accessing this property while it is updated by another does the transaction work like a mutex? I would expect it to do so but I find very little documentation about the TransactionService and nothing about how simultaneous access is handled. What I want to avoid is that the property is updated by one client and another client access the property before the new value has be set.

Any TransactionService master out there that could explain this to me?
Thanks,

[lotharm]

There is no mutex or semaphore mechanism build in. Instead, Alfresco uses the optimistic locking feature of Hibernate to avoid this kind of errors. One transaction will receive an exception on commit to indicate that the data has changed.

It would be very helpful to have a counter or sequencing mechanism build into Alfresco, indeed.

If you would like to avoid any concurrent updates, you would have to add some locking or recovering code.

Regards

[calle]

Thanks
By that you mean that the optimistic locking feature of Hibernate will cause the transaction to throw an exception if the property value has changed when it is written? If I understand you correctly there is no exception thrown if the value is read by two threads simultaneously or written by one thread and read by anouther?

It is easy to implement standard java synchronization to resolve this, as long as you are not running on a clustered system… I do not know how to solve the synchornization in that case. What I had hoped for was that some underlying service in Hibernate or Alfresco would handle it.

Any ideas?

[mrogers]

The behaviour of your code will be dependent upon your database's isolation level.  

I think there is a fair chance that your code will work correctly, it's certainly worth you running some tests on your environment.   The second transaction should retry after the concurrent update exception.

Sequential indexing is always problematic in distributed systems, and for this reason it is best avoided if possible.

[lotharm]

Records Management could be a use case. The file plan requires almost always the generation of some unique id.
So a SequenceService may be a handy thing that could take of it at the database level.

Regards