Oh, I also get OConcurrentModificationExceptions, wich seems a bit weird as well, since I am the only user, commiting 1 record at a time...
On Friday, February 20, 2015 at 12:16:06 PM UTC+1, Bjorn Cintra wrote: > > Yeah, I figured yours was the same problem > > It seems that if I wait long enough, the connections get syncronized, and > they see the same result. I can live with an eventual type of consistency > (as I can mask it using client side JavaScript), but only if it takes <1 > second to update. > > The Gremlin shell never updates. > > On Friday, February 20, 2015 at 12:03:18 PM UTC+1, Aris Alexis wrote: >> >> https://groups.google.com/forum/#!topic/orient-database/ERs4eaSGAjI >> >> I have been debugging the same problem and it drives me crazy! >> >> On Friday, February 20, 2015 at 11:20:09 AM UTC+1, Bjorn Cintra wrote: >>> >>> Hi >>> >>> My use case scenario is a web app, where the OrientGraphFactory is >>> instanced as a Singleton Provider using Google Guice, and each use of >>> OrientGraph is bound to the ResuestScope, aka each request get a potential >>> different graph thread instance. I am the only user at the moment. >>> >>> All Vertexes and Edges extends ORestricted, and the OrientGraphFactory >>> is created using a tenant user and password to limit visibility towards >>> other tenants. >>> >>> I have a GroupDAO that has a method updateRoles that takes a Group and a >>> List of roles, and first remove all exiting edges between the Group and the >>> Roles, and then re-add the Edges. >>> >>> @Override >>> void updateRoles(IGroup group, List<String> roles) { >>> try { >>> // 1.) Remove old connections >>> graph.getVertex(group.getId()).outE('member').remove() >>> >>> // 2.) Add all new >>> Vertex vGroup = graph.getVertex(group.getId()) >>> >>> roles.each { String role -> >>> Vertex vRole = graph.getVertex(role) >>> Edge member = graph.addEdge(null, vGroup, vRole, "member"); >>> log.info('log: role: {}, member: {}', role, member) >>> } >>> graph.commit() >>> } catch( Exception e ) { >>> log.error(e.getMessage(), e) >>> graph.rollback(); >>> throw e >>> } >>> } >>> >>> >>> Using the web-flow of POST->redirect->GET, the get call after the update >>> will in turn call getRoles to get the updated list of Roles from the >>> database >>> >>> @Override >>> List<IRole> getRoles(IGroup group) { >>> List<IRole> roles = [] >>> graph.commit() >>> def result = graph.getVertex(group.getId()).outE('member').inV >>> while(result.hasNext()){ >>> roles << OrientHelper.fromVertex(result.next(), Role.class) >>> } >>> >>> return roles >>> } >>> >>> >>> OritentHelper.fromVertex is a helper class i use to reflect Vertex onto >>> a bean instance. >>> >>> So to my actual problem(s): >>> >>> 1.) The get request contains a result that is not consistent. As each >>> request uses a different thread, and graph instance from the pool, it will >>> sometimes get the updated result, and sometimes the old result. The old >>> result does not go away until another update, but then the result reflect >>> the new updates, with the same problem. It seems like a cache issue to me. >>> >>> 2.) Using the Gremlin shell, the Edges never gets updated. It will keep >>> listing the old Edges until the graph is closed and reopened. The web >>> interface shows the updated Edges. >>> >>> I am using OrientDb 2.0.2, Java 8, Linux and Groovy 2.3.7 on a remote >>> (localhost) connection. I am using Gremlin 2.6.0. >>> >> -- --- 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
