For systems that do not have nested commits the joined commit means that the outer most commit does the commit.
That is the contract. On Thu, Jul 24, 2014 at 12:40 PM, Andy Seaborne <a...@apache.org> wrote: > I won't override begin/commit/end to do this. > > FWIW I think the idea that "commit()" does not actually cause a persistent > change on disk is bad. The contract on commit() is ACID, specifically D > so ".commit() ; System.exit(0) - restart" smeans teh app is guarantteed to > see the change. > > This is just reference counting? > What happens if the nesting never un-nests? > > Better is to separate concepts and have a counter - that is a samll > mamangement library for trasnactions: > > TransactionLevelMgt mgr = new TransactionLevelMgt(dataset) ; > > mgr.beginLevel(dataset, WRITE) ; > mgr.endLevel() ; > mgr.abort() ; > > and endLevel does a "commit()" when the level count returns to zero. > > > > Assume a QueryResult object that comprises the result set from > > a query and the dataset it was run against. > > Surely the right way is to create a detached result set? (no tied to the > transaction or the query execution) > > Andy > > > On 24/07/14 10:32, Claude Warren wrote: > >> As you can probably guess from my recent posts here, I am working with >> transactions, datasets, and web applications. >> >> In Spring there is this concept of "joining a transaction". Basically it >> works like this: >> >> When calling begin() >> >> If a transaction is in progress and is the proper type (Write request must >> be write, Read request may be Read or Write) use it. >> >> if a transaction is in progress and is not the proper type (write request >> with read transaction in progress) throw an exception >> >> if no transaction is in progress start one of the proper type. >> >> when calling commit() >> >> if we joined the transaction do nothing. >> >> if we started the transaction commit it. >> >> when calling abort()/rollback() >> if we joined the transaction throw an exception >> if we created the transaction abort rollback the transaction. >> >> In our special case of end() I think we would do something like commit(). >> >> I have a class that handles this by wrapping the real dataset and >> providing >> this functionality via thread local variables. >> >> usage case is something like: >> >> In a web service we have a query and a dataset to query against. We want >> to stream the results to the client without creating the potentially large >> file locally. >> >> Assume a QueryResult object that comprises the result set from a query and >> the dataset it was run against. >> >> >> 1. service call comes in to a JAX-RS annotated service >> 2. service starts a READ transaction. >> 3. execute the query >> 4. returns a QueryResult (see above) >> 5. system uses a @Provider annotated class to format the result as per >> the request. >> 6. the transaction.end() is called. >> >> >> >> As you can see the transaction is started in one object and is logically >> not complete until the end of an second object. >> >> If anyone is interested I'll put the class in the jena-commons. >> >> >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
