We started discussing how an implementation would look, but bumped into problems.
The plan was to look at potentially adding a restful transaction API, something like "create a transaction context resource via a POST, and then work with the database "via" that context resource, commiting/aborting it when done". The problem with this approach, and with any other HTTP-based approach that we could come up with that allows real over-the-wire transactions, is that we have no easy way of knowing if a client has crashed. We could potentially end up with a ton of open transactions holding locks on the DB, and wouldn't know if the clients were still around. With an approach that's closer to the network, we can roll back transactions if the connection dies, but doing that with HTTP is a lot harder. The idea of transactional support over the wire is still very much alive, but it will probably not be done over HTTP.. /Jake On Wed, May 11, 2011 at 12:21 PM, Aseem Kishore <aseem.kish...@gmail.com>wrote: > Just wanted to ask: how'd the lab day go last Friday? Any updates on this? > =) > > Cheers, > Aseem > > On Thu, May 5, 2011 at 7:42 AM, Mattias Persson > <matt...@neotechnology.com>wrote: > > > 2011/5/5 Aseem Kishore <aseem.kish...@gmail.com> > > > > > Yes, great points. > > > > > > I've worked a good deal with Microsoft's cloud NoSQL DB, Windows Azure > > > Table > > > Storage, and for what it's worth, I thought they solved this problem > very > > > elegantly. That API is entirely REST-based, and they use HTTP If-Match > / > > > If-Modified-Since headers to achieve conditional requests, which gets > > them > > > optimistic concurrency like I described below. > > > > > > E.g. if you want to read and update a row, your update request (e.g. > PUT) > > > is > > > conditional based on what you expect the value to be (specified via the > > > If-* > > > header or headers). If it's no longer that value, the request will > fail, > > so > > > you can re-read and try again. This allows it to be nicely scalable > since > > > it > > > doesn't require transactions AKA locks. > > > > > > Part of the problem for Neo4j though is that (a) the index is separate > > from > > > the graph, which requires separate manual operations, and (b) the index > > > supports multiple nodes under a single key/value pair, which doesn't > lend > > > itself to a "fail if a node already exists" metaphor. > > > > > > I know you guys are working on solving (a) in the next release, but I > > would > > > also love an alternative to (b), e.g. being able to specify (whether at > > an > > > index level, a key/value pair level, or a query/request level) that I > > > *don't* want multiple nodes under the same key/value pair in an index. > > > > > > > I have also think that such an index type is good to have, for just this > > and > > for performance reasons in that you can do low-level optimizations if you > > know that there will be only zero or one node/relationship for a given > > key/value pair in an index. Hopefully there will be time for that soon :) > > > > > > > > Thanks much for your consideration! And good luck. =) > > > > > > Aseem > > > > > > On Thu, May 5, 2011 at 1:00 AM, Peter Neubauer < > > > peter.neuba...@neotechnology.com> wrote: > > > > > > > Assem, > > > > I agree. The problem is not the database API IMHO, but the > mismatching > > > > semantics of HTTP REST and transactional DB APIs, and the balancing > of > > > > shoving over work to the database server via server side processing > > > > scripting or plugins and client side operations via HTTP. Let's see > if > > > > we can come up with a first prototype. > > > > > > > > Cheers, > > > > > > > > /peter neubauer > > > > > > > > GTalk: neubauer.peter > > > > Skype peter.neubauer > > > > Phone +46 704 106975 > > > > LinkedIn http://www.linkedin.com/in/neubauer > > > > Twitter http://twitter.com/peterneubauer > > > > > > > > http://www.neo4j.org - Your high performance graph > > > database. > > > > http://startupbootcamp.org/ - Öresund - Innovation happens HERE. > > > > http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing > > party. > > > > > > > > > > > > > > > > On Thu, May 5, 2011 at 9:26 AM, Aseem Kishore < > aseem.kish...@gmail.com > > > > > > > wrote: > > > > > Thanks Peter. Looking forward to seeing what you guys come up with! > > > > > > > > > > Dima, thanks for the tip. It would be nice to not to have to write > a > > > > custom > > > > > plugin for what's arguably a pretty fundamental need from database > > > APIs. > > > > =) > > > > > > > > > > Aseem > > > > > > > > > > On Wed, May 4, 2011 at 2:05 PM, Peter Neubauer < > > > > > peter.neuba...@neotechnology.com> wrote: > > > > > > > > > >> Guys, > > > > >> Friday is labday, so we there are tentative plans to sketch on > some > > > > >> transactional semantics in the REST API and circle back to the > list > > on > > > > >> that. Let's see how it goes! > > > > >> > > > > >> Cheers, > > > > >> > > > > >> /peter neubauer > > > > >> > > > > >> GTalk: neubauer.peter > > > > >> Skype peter.neubauer > > > > >> Phone +46 704 106975 > > > > >> LinkedIn http://www.linkedin.com/in/neubauer > > > > >> Twitter http://twitter.com/peterneubauer > > > > >> > > > > >> http://www.neo4j.org - Your high performance graph > > > > database. > > > > >> http://startupbootcamp.org/ - Öresund - Innovation happens > HERE. > > > > >> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing > > > party. > > > > >> > > > > >> > > > > >> > > > > >> On Wed, May 4, 2011 at 8:59 PM, Dima Gutzeit > > > > >> <dima.gutz...@mailvision.com> wrote: > > > > >> > You should implement your own plugin/component on the standalone > > > neo4j > > > > >> > server and expose you own API that makes batch operations. > > > > >> > > > > > >> > Regards, > > > > >> > Dima Gutzeit. > > > > >> > > > > > >> > Sent from my iPhone > > > > >> > > > > > >> > On 4 במאי 2011, at 21:56, Aseem Kishore < > aseem.kish...@gmail.com> > > > > wrote: > > > > >> > > > > > >> >> Re-sending in the hopes that someone has answers to or thoughts > > on > > > > this. > > > > >> =) > > > > >> >> > > > > >> >> Aseem > > > > >> >> > > > > >> >> On Mon, May 2, 2011 at 4:16 PM, Aseem Kishore < > > > > aseem.kish...@gmail.com > > > > >> >wrote: > > > > >> >> > > > > >> >>> Hi there, > > > > >> >>> > > > > >> >>> If we're using Neo4j purely over REST, do we have any means to > > > > protect > > > > >> >>> against concurrency? The REST API appears to expose neither > > > > >> transactions nor > > > > >> >>> optimistic concurrency. > > > > >> >>> > > > > >> >>> Here's a simple example: we have nodes representing users, and > > > users > > > > >> have a > > > > >> >>> "username" property that we index. When a new user signs up > and > > > > >> requests a > > > > >> >>> particular username, we'd like to only give it to them if that > > > > username > > > > >> >>> isn't taken. > > > > >> >>> > > > > >> >>> If we simply query the index for the specified username, > reject > > it > > > > if a > > > > >> >>> node already exists for that username, otherwise accept it and > > > > create a > > > > >> new > > > > >> >>> node and index it, then this opens us up to a classic race > > > > condition. > > > > >> >>> > > > > >> >>> Having an "atomic get or create" operation (essentially a > > > > transaction) > > > > >> over > > > > >> >>> the REST API would solve this. > > > > >> >>> > > > > >> >>> Alternately, having conditional operations ("add this > > > node+username > > > > to > > > > >> the > > > > >> >>> index only if the index still has no other node for that > > > username") > > > > >> would > > > > >> >>> also this, since we would fail and try our request again, > seeing > > > now > > > > >> the > > > > >> >>> username already exists (optimistic concurrency). > > > > >> >>> > > > > >> >>> Are we missing anything? Is any of this possible today? If > not, > > it > > > > >> would be > > > > >> >>> great to see some sort of support for concurrency over the > REST > > > API > > > > in > > > > >> a > > > > >> >>> future release. =) > > > > >> >>> > > > > >> >>> Thanks! > > > > >> >>> > > > > >> >>> Aseem > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > > >> >> _______________________________________________ > > > > >> >> Neo4j mailing list > > > > >> >> User@lists.neo4j.org > > > > >> >> https://lists.neo4j.org/mailman/listinfo/user > > > > >> > _______________________________________________ > > > > >> > Neo4j mailing list > > > > >> > User@lists.neo4j.org > > > > >> > https://lists.neo4j.org/mailman/listinfo/user > > > > >> > > > > > >> _______________________________________________ > > > > >> Neo4j mailing list > > > > >> User@lists.neo4j.org > > > > >> https://lists.neo4j.org/mailman/listinfo/user > > > > >> > > > > > _______________________________________________ > > > > > Neo4j mailing list > > > > > User@lists.neo4j.org > > > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > > > > _______________________________________________ > > > > Neo4j mailing list > > > > User@lists.neo4j.org > > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > > _______________________________________________ > > > Neo4j mailing list > > > User@lists.neo4j.org > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > > > > > > -- > > Mattias Persson, [matt...@neotechnology.com] > > Hacker, Neo Technology > > www.neotechnology.com > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Jacob Hansson Phone: +46 (0) 763503395 Twitter: @jakewins _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
