But then it would be possible to write a RequestFilter for the Neo4j-Server that does start and commit/rollbacks transactions.
I.e. you create a tx object and put it in the session-context if there is none and return a tx-token that the filter uses (e.g. as header-field). then later you can pull it out again and attach it to the current thread (that's the tricky part). On commit or rollback you just do that with the tx (after attaching it to the thread). As the RestfulGraphDb and the Filter share the same execution thread this could/should work. I wouldn't want to support that in the neo4j server by default as this creates a lot of server-side state that has to be managed. But if it works out one could publish that as server-extension. HTH Michael Am 07.07.2011 um 13:30 schrieb Patrik Sundberg: > Following up on the topic of transactions for client API. > > What is the current plan for some sort of client side API supporting > transactions? > > I'm playing around with some ideas here and the lack of transaction support > in the client API is problematic. I know there's BATCH support in the REST > API which effectively is a transaction, but it doesn't always suit. For > example I have the following steps that I'd like to accomplish: > - create a reference node > - check if a node with a given domain id exist in an index, if it does, fail > - create an entity node for the given domain id > - add entity node to the index > - attach entity node to ref node > - create a node representing a specific version of the entity node > - attach the version node to the entity node, with some properties on the > relationships signifying valid time > > That should all be considered an atomic operation, all or nothing. Doing it > step by step is very easy and natural with REST API, but trying to roll back > on error is flaky. > > I think could batch it, but from a programming style it becomes pretty > unnatural. Same thing with a plugin for doing the steps. The natural flow of > code client side gets distorted by having to collect a lot of data upfront > and then provide all that data to a method call. It's doable, just doesn't > seem ideal. > > Using an embedded db, exposing as some sort of service etc is also doable, > it's just that my domain is graph related and I'm pretty happy with just the > "primitives" and using a remote server (if I could have transactions). > Number of clients are quite a few and need to share their data + don't all > run all the time so can't make the client API the embedded api. > > I'd think it's not an uncommon situation and many people wishing for a > support for natural client side transaction API (similar to embedded api). > > Patrik > > > On Tue, Jul 5, 2011 at 12:27 PM, Patrik Sundberg > <patrik.sundb...@gmail.com>wrote: > >> yeah, harder problem than my first hunch. >> >> sounds like plugins is the way to go for now, hopefully introduction of >> non-rest protocol with same interface as embedded API in 1.5 will simplify >> things in the future. >> >> thanks >> >> >> On Mon, Jul 4, 2011 at 11:07 PM, Michael Hunger < >> michael.hun...@neotechnology.com> wrote: >> >>> Patrick, >>> >>> I've already thought long and hard about that. >>> >>> The problem is you can't implement that transparently as you can never >>> allow code in a second call rely on data derived from a previous one. >>> >>> The simplest form that I came up with is a "BatchCommand" that gets an API >>> interface injected that allows requests but doesn't return data. >>> >>> The execution of this Batch command would then return a "BatchResult" with >>> all the data acquired during the batch operation. >>> >>> Another way would be to inject the normal GraphDatabaseService interface, >>> record the invocations in a first phase and then execute the batch command >>> again (this time ignoring the inputs but then returning the results) but >>> this is bad from a usability perspective. >>> >>> One critical issue is the creation of relationships as they depend on the >>> correct node-ids of previously created nodes. Jacob already thought about >>> some means of referring to previous output data but I think kept away from >>> that as we didn't want to make this batch-interface a turing complete >>> language. >>> >>> So you see, it's not that simple. >>> >>> Michael >>> >>> Am 27.06.2011 um 20:45 schrieb Patrik Sundberg: >>> >>>> Hi, >>>> >>>> Since there is now possible to send off batches of operations via the >>> REST >>>> interface, I was wondering if anyone has started to look at implementing >>>> transactions in the java REST client ( >>>> https://github.com/jexp/neo4j-java-rest-binding) ? >>>> >>>> It would seem possible, but I can also see it could involve some major >>>> reorganizing of the internals of the client to make everything aware of >>>> transactions and submit via batch command. >>>> >>>> Patrik >>>> _______________________________________________ >>>> 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
