Thanks for the update Jake! Given that one of the principal goals behind HTTP and REST is scalability (distributability), your mail reaffirms my appreciation for optimistic concurrency -- no complex transaction semantics needed.
The way Windows Azure implemented it was pretty straightforward: 1. All RESTful responses for a resource included a Last-Modified header and/or an E-Tag. (Off the top of my head, I can't remember if it was both or one or the other depending on the resource.) 2. You could send all RESTful requests to resources with an If-Unmodified-Since: <Date> or If-Match: <E-Tag> header. 3. If the condition you specified in your request is no longer true, the request fails w/ a response of 412 Precondition Failed. Any thoughts on applying these semantics to Neo4j? Here are a couple of examples: - Have *GET /node/123/properties* return a Last-Modified and/or E-Tag header, and let me send an If-Unmodified-Since or If-Match header when I put *PUT* or *DELETE* /node/123/properties. - Same for individual properties. (This may be a good candidate for E-Tag rather than tracking Last-Modified for every property.) Same for relationship properties too. - And most importantly, same for adding to the index: *GET* and *POST* to* /index/<type>/<name>/key/value*. *This would solve my problem*. =) Thanks for your consideration! Aseem On Wed, May 11, 2011 at 8:01 AM, Rick Bullotta <rick.bullo...@thingworx.com>wrote: > I think you have to still do it over HTTP *in addition* to any other > transport, if for no other reason than the ubiquity of HTTP-capable client > applications/platforms/languages. That said, I'd implement a pessimistic > transaction recovery scheme with a configurable "time to live". > > -----Original Message----- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] > On Behalf Of Jacob Hansson > Sent: Wednesday, May 11, 2011 10:58 AM > To: Neo4j user discussions > Subject: Re: [Neo4j] REST API (optimistic or transactional) concurrency? > > 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 > _______________________________________________ > 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
