Not sure what the problem you have now with the long running transactions is. If it is memory then no, suspend will not free any memory at the moment but you gave me an idea there. Suspend could be use as an indication to "free memory" so if transaction is holding a lot of memory a suspend could cause the memory to be freed earlier when we have that type of functionality.
If the problem with long running transactions has to do with locks (a lock is held by one transaction and you want another to get that lock) then no, suspend does currently not work that way. Only way to fix that is to change the locking implementation and by doing so also changing transaction isolation level. We should discuss this for the 1.1 release. I am currently looking at optimizing the locking implementation for the 1.0 release but as of now I don't think we should change the "transaction isolation level semantics" without discussing it throughly. -Johan On Sun, Jun 8, 2008 at 12:01 PM, Tobias Ivarsson <[EMAIL PROTECTED]> wrote: > On Fri, Jun 6, 2008 at 2:05 PM, Johan Svensson <[EMAIL PROTECTED]> wrote: >> >> Also in the next few days we will merge in the "transaction fix" >> branch that ties locking to transactions instead of threads. This >> means you can run two transactions in the same thread using JTA >> suspend/resume. > > Could the JTA suspend/resume functionality be used to better support > long running transactions? Or will long running transactions still be > inefficient? > The case I want to support is: > 1. Load up a transaction, maybe create a few nodes. > 2. Suspend the transaction for an undefined amount of time. > 3. [0 or more times] resume the transaction and do some minor > actions, create a few nodes and relationships. Then suspend the > transaction again. > 4. Resume the transaction and perform a larger set of actions (at > least as big as an action in step 3, but most likely a lot more), > create nodes/relationships, remove nodes/relationships, update > properties. > 5. Commit the transaction. (No suspending between step 4 and 5). > > Probably half of the work or more will be performed in step 4-5. For > really small transactions step 1 might be as big as step 4, but the > larger the transaction, the more of it will be done in steps 3-5. > The problem is of course that the time from step 1 to step 4 is > unknown. It would be great if we could use the suspend/resume > functionality to make this use case more efficient. Perhaps (if memory > usage is the problem with our support for long running transactions) > push some of the changes in the suspended transactions to some > intermediate, temporary, state on disk. > > Am I hoping for too much here or could this be supported? Because it > could make the Qi4j-plug-in a lot better. I wrote the code for it in a > dream this night, and it's great. It will definitely work, simplifying > a lot of things on the Qi4j-user side of things, while still > supporting small updates to huge datasets, which is an area where the > current plug-in excels, but at the cost of some inconvenience for the > user. > > -- > Tobias Ivarsson <[EMAIL PROTECTED]> > Hacker, Neo Technology > www.neotechnology.com > Cellphone: +46 706 534857 > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
