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 only some objects have changes and you have enough memory to keep them in a DataContext.
Or if you need to flush data to DB in smaller chunks without committing a DB transaction, you can still do it by temporary re-bidning your own transaction to the current thread for the duration of commit, and then restoring it to the iterated query transaction when update is done. Andrus On Dec 29, 2010, at 3:25 PM, Hans Pikkemaat wrote: > 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 iterated query. > > So any updates executed while the iterated query is running will be committed > when the > iterated query (actually the Result Iterator) is closed. So the iterator is > committing the > updates for me what I don't want. > > I know I can create my own transaction but this doesn't help me. I want to be > able to > create a transaction and within that transaction I want to run the iterated > query and > while in the query I want to do updates which are committed when I commit my > own > transaction. > > Question: Is there a way to prevent the iterated query to 'hyjack' my > transaction? > > pseudo code > > create datacontext (my transaction) > run iterated query (overrides my transaction) > process data > do some updates (will use the transaction of the > iterator) > close iterator (will commit my updates. I don't want this) > commit my updates (does nothing as its already committed by the > iterator) > > tx > > Hans > > PS: I'm using cayenne 2.0.4 >
