Hi, How you get/release db instances? Lvc@
On 29 January 2015 at 10:45, odbuser <[email protected]> wrote: > I still get the error occasionally without the clearing the cache before > use. Only one thread reads and writes these particular records at a time. > It is happening fairly frequently in this particular test which has 3 > concurrent threads from a pool of 10. Every 30 seconds, records are > updated. In other words a write to a specific record occurs and then 30 > seconds later that record is updated by a different thread. I've seen 20 > of these errors over about 30 minutes. I don't think the cache working as > stated so I must clear it with the code I mentioned. > > com.orientechnologies.orient.core.exception. > OConcurrentModificationException: Cannot UPDATE the record #22:0 because > the version is not the latest. Probably you are updating an old record or > it has been modified by another user (db=v1247 your=v1229) > at com.orientechnologies.orient.core.conflict. > OVersionRecordConflictStrategy.checkVersions( > OVersionRecordConflictStrategy.java:54) ~[na:na] > at com.orientechnologies.orient.core.conflict. > OVersionRecordConflictStrategy.onUpdate(OVersionRecordConflictStrategy. > java:41) ~[na:na] > at com.orientechnologies.orient.core.storage.impl.local. > OAbstractPaginatedStorage.checkAndIncrementVersion( > OAbstractPaginatedStorage.java:2009) ~[na:na] > at com.orientechnologies.orient.core.storage.impl.local. > OAbstractPaginatedStorage.doUpdateRecord(OAbstractPaginatedStorage.java: > 1643) ~[na:na] > at com.orientechnologies.orient.core.storage.impl.local. > OAbstractPaginatedStorage.updateRecord(OAbstractPaginatedStorage.java:726) > ~[na:na] > at com.orientechnologies.orient.core.db.document. > ODatabaseDocumentTx.executeSaveRecord(ODatabaseDocumentTx.java:1719) ~[na: > na] > at com.orientechnologies.orient.core.tx.OTransactionNoTx. > saveRecord(OTransactionNoTx.java:94) ~[na:na] > at com.orientechnologies.orient.core.db.document. > ODatabaseDocumentTx.save(ODatabaseDocumentTx.java:2271) ~[na:na] > at com.orientechnologies.orient.core.db.document. > ODatabaseDocumentTx.save(ODatabaseDocumentTx.java:117) ~[na:na] > at com.orientechnologies.orient.core.record.impl.ODocument.save( > ODocument.java:1747) ~[na:na] > at com.orientechnologies.orient.core.record.impl.ODocument.save( > ODocument.java:1738) ~[na:na] > at com.tinkerpop.blueprints.impls.orient.OrientElement.save( > OrientElement.java:304) ~[na:na] > at com.tinkerpop.blueprints.impls.orient.OrientElement.save( > OrientElement.java:284) ~[na:na] > at com.tinkerpop.blueprints.impls.orient.OrientElement.setProperty > (OrientElement.java:186) ~[na:na] > at com.tinkerpop.frames.annotations.PropertyAnnotationHandler. > processElement(PropertyAnnotationHandler.java:34) ~[na:na] > at com.tinkerpop.frames.annotations.PropertyAnnotationHandler. > processElement(PropertyAnnotationHandler.java:11) ~[na:na] > at com.tinkerpop.frames.FramedElement.invoke(FramedElement.java:89 > ) ~[na:na] > > > > > On Monday, January 26, 2015 at 5:25:16 AM UTC-5, Andrey Lomakin wrote: >> >> HI, >> You should not do this. It would be very inconvenient, it is done >> automatically now. We had issue with DB life cycle management in previous >> pool implementation now it is fixed. >> I remember that we had similar kind of discussion with you in mailing >> list and I promised you that it will be fixed in 2.0 :-) . >> >> >> On Sat, Jan 24, 2015 at 10:34 AM, odbuser <[email protected]> wrote: >> >>> Luca, the cache behavior still needs to be clarified in the >>> documentation. I've seen this question asked a few times but not fully >>> addressed unless I am missing something. >>> >>> In other words before every "request" in my app I have to do the >>> following to the open graph otherwise writing in a thread followed by a >>> read from another where that data was cached results in a dirty read: >>> >>> OrientGraph orientGraph = ... >>> ODatabaseDocumentTx rawGraph = orientGraph.getRawGraph(); >>> OLocalRecordCache localCache = rawGraph.getLocalCache(); >>> localCache.invalidate(); >>> >>> Is this what users are expected to do? If so, it's a major use case >>> that needs to be explicit in the documentation. >>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Best regards, >> Andrey Lomakin. >> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
