good idea. i'll ponder it for a bit. but yes, we clearly need to keep state around, so for REST it'd be carried around in session. but on server side I guess you have issues with never ending transactions, how to cull them, etc. since it's a stateless req/response comm channel. on a permanent channel it's easy to detect disconnect and clean up, over http not as easy.
thanks On Thu, Jul 7, 2011 at 12:42 PM, Michael Hunger < michael.hun...@neotechnology.com> wrote: > 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 > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
