Re: transactions vs iterated query

2011-01-06 Thread Hans Pikkemaat
Hi, That sounds logical but the issue could be that the calling party is simply not aware that the called library is using cayenne. This would mean that an application which is calling some library always should clear (and keep) the transaction. This is not very logical. And what about the ot

Re: transactions vs iterated query

2011-01-06 Thread Andrus Adamchik
On Jan 6, 2011, at 10:48 AM, Hans Pikkemaat wrote: > One library calls the other one. > The first one is using the iterated query to get some data. It will call the > second > library to process the data. IMO this first library (iterator control code) should be the place that does transaction

Re: transactions vs iterated query

2011-01-06 Thread Hans Pikkemaat
Hi, After some investigation it comes down to two problems 1) An example. I have 2 libraries. One library calls the other one. The first one is using the iterated query to get some data. It will call the second library to process the data. This second library however is not aware of a iterated

Re: transactions vs iterated query

2011-01-05 Thread Andrus Adamchik
Haven't thought about this scenario deeply... How about this: In the simplest case you can keep your changes in the DataContext while iterating over the result (DataContext by itself is not permanently bound to a transaction). And then commit them after iteration is finished. This will work if

transactions vs iterated query

2010-12-29 Thread Hans Pikkemaat
Hi, I'm using an iterated query to process a huge amount of data which cannot be loaded at once. This query creates its own transaction and binds it to the current thread. This means that when I process the data I received from the iterated query all queries use the transaction created by the