Transaction questions.

Skip to first unread message

Johan Sjöberg

Sep 1, 2015, 7:35:32 AM9/1/15
to OrientDB

We are using orientDB in a webapp that uses a REST api combined with Orients Java Object api.
We will almost exclusively only need transaction when updating an object but currently we do not 
track the version in REST api. The latest update call for a certain object is thus considered the latest version.
The problem is that an update to one object might affect another, thus we need transactions, preferably optimistic ones.

We don't entirely understand the documentation but our basic approach have been:

for (int i = 0; i < TRANSACTION_RETRY_COUNT; i++) {
try {
= tempObject ;
} catch (OConcurrentModificationException e) {
throw e;

That is, the userUpdatedObject is not tracked  by the db. It comes from the REST api and doesn't have any version.
  • When is the OConcurrentModificationException? I am assuming in the commit function?
  • We get a OConcurrentModificationExceptionWe catch the exception and retry, how does the begin() function know that the previous transaction was aborted and it should start a new one and not a nested transaction?
    • Do we need to do a rollback after we caught the OConcurrentModificationException? Or is that already done when the exception is thrown? Basically, when do we need to manually rollback?
    • What would happen if, for example, doStuff() throw another type of exception, AnotherException, that we also catch. Will it be a nested transaction then? 
      • If so, do we need to do a rollback after we catch AnotherException?
  • What is the difference between db.getTransaction().begin() and db.begin()? With the later one I can choose transaction strategy (except only optimistic is supported). Which one should we be using?
Overall, is this the correct approach or how should one go about it? Thanks for all the help!

Reply all
Reply to author
0 new messages