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
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
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
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
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