The detached result set takes more memory, no? So for large results on a heavily loaded system this is an issue. In addition creating a detached set takes time, so in systems where response times are critical it may makes sense to return the streaming result set.
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
