Fixed. On Fri, Oct 24, 2014 at 12:21 PM, Emanuele Milani < [email protected]> wrote:
> Thank you very much! > > On Friday, October 24, 2014 9:49:11 AM UTC+2, Andrey Lomakin wrote: >> >> HI, >> I will look at it https://github.com/orientechnologies/orientdb/ >> issues/2977 next week . >> >> >> >> On Fri, Oct 24, 2014 at 10:44 AM, Rani Pinchuk <[email protected]> >> wrote: >> >>> Hi all, >>> >>> >>> >>> Could this question be clarified indeed? >>> >>> >>> >>> Is it correct that two Vertex objects which are referring to the same >>> record cannot be used safely? So, when a change to the record is done using >>> one of the Vertex object, is this change reflected always when using the >>> other Vertex object (which refers to the same record)? >>> >>> >>> >>> If this is not the case, then a cache which will cache Vertex objects >>> could be used. The client will never get a Vertex object unless from the >>> cache, and this way, the cache can make sure that there is at most one >>> Vertex object available at each point in time for each record. >>> >>> >>> >>> When working with threads, such a cache will have to be created per >>> graph object, and the different caches will have to communicate with each >>> other somehow (directly or indirectly), trigger refreshes to some Vertex >>> objects that may have been updated by an object of the other cache. So not >>> at all simple… >>> >>> >>> >>> Actually the local cache (mentioned here: http://www.orientechnologies. >>> com/docs/last/orientdb.wiki/Caching.html) may suggest that something >>> like that is already implemented, although it seems that it does not work >>> well in the example given by Emanuele. In addition, I am not sure how it >>> behaves with respect to concurrency. >>> >>> >>> >>> Is there already such mechanism designed in OrientDB, and this thread >>> discusses a bug in this mechanism, or there is no such mechanism and we >>> should never trust situations where two Vertex objects refer to the same >>> record? >>> >>> >>> >>> Thanks for clarifying this. >>> >>> >>> >>> Rani >>> >>> On Tuesday, October 21, 2014 1:03:08 PM UTC+2, Andrey Lomakin wrote: >>>> >>>> Hi >>>> I got reason of your issue, could you try 2.0-SNAPSHOT. >>>> Problem should be fixed there. >>>> >>>> >>>> On Tue, Oct 21, 2014 at 1:59 PM, Andrey Lomakin <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> Do you have local cache enabled ? >>>>> It explicitly created to avoid such problems. >>>>> >>>>> On Tue, Oct 21, 2014 at 12:48 PM, Emanuele Milani < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi all! >>>>>> >>>>>> I am in the process of debugging an application based on OrientDB >>>>>> (2.0M2). The problem I am facing are some >>>>>> OConcurrentModificationException. >>>>>> The issue appears with both the "memory" and the "plocal" storage engines >>>>>> (I did not try "remote"). It looks they are caused by the fact that >>>>>> multiple OrientVertex objects which refer to the same database record are >>>>>> (in general) not in sync. This also means that there is no guarantee in >>>>>> general that a value which is returned by a query is the most up to date. >>>>>> The following code replicates the issue. I agree it may look a bit >>>>>> awkward, but it is just the smallest example I could come up with from >>>>>> our >>>>>> code. >>>>>> >>>>>> OrientGraphFactory graphFactory = new OrientGraphFactory(DATABASE_URL >>>>>> ); >>>>>> graphFactory.setAutoStartTx(false); >>>>>> OrientGraph graph = graphFactory.getTx(); >>>>>> >>>>>> graph.begin(); >>>>>> OrientVertex firstVertexHandle = graph.addVertex(null, PROPERTY_NAME, >>>>>> 0); >>>>>> graph.commit(); >>>>>> firstVertexHandle.setProperty(PROPERTY_NAME, 1); >>>>>> >>>>>> // Note that if any of the following 3 lines are commented, then the >>>>>> problem does not appear >>>>>> graph.begin(); >>>>>> graph.getVertices("someproperty", "somevalue").iterator().hasNext(); >>>>>> graph.commit(); >>>>>> >>>>>> Object vertexId = firstVertexHandle.getId(); >>>>>> >>>>>> Vertex secondVertexHandle = graph.getVertex(vertexId); >>>>>> secondVertexHandle.setProperty(PROPERTY_NAME, 2); >>>>>> >>>>>> // prints 1 >>>>>> System.out.println(firstVertexHandle.getProperty(PROPERTY_NAME)); >>>>>> // prints 2 >>>>>> System.out.println("Value queried from the second vertex handle is " >>>>>> + secondVertexHandle.getProperty(PROPERTY_NAME)); >>>>>> >>>>>> // The following throws an OConcurrentModificationException >>>>>> firstVertexHandle.setProperty(PROPERTY_NAME, 3); >>>>>> >>>>>> >>>>>> Is this a bug in OrientDB? >>>>>> What should the expected behavior with respect to multiple Vertex >>>>>> objects referring to the same database record? >>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> 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. >>>>> >>>>> Orient Technologies >>>>> the Company behind OrientDB >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Andrey Lomakin. >>>> >>>> Orient Technologies >>>> the Company behind OrientDB >>>> >>>> -- >>> >>> --- >>> 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. >> >> Orient Technologies >> the Company behind OrientDB >> >> -- > > --- > 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. Orient Technologies the Company behind OrientDB -- --- 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.
