cancel
Showing results for 
Search instead for 
Did you mean: 

Transaction not committing in web script

billhole
Champ in-the-making
Champ in-the-making
I have written a web script that searches for a set of nodes of a particular type that were created in a specified date range, then deletes each node and recreates it with the same data (this is intended to fix a problem that is out of the scope of this question). The code that re-creates the node does a search first to confirm that the node does not exist.

I have each delete and create enclosed in a transaction. When I run in the debugger and trace through the code, everything works because the deleted node is not found. If run without the debugger, the search for the existing node returns a result, with all the fields marked as "missing". Because the node already (incompletely) exists, the new node is not created.

The web script definition has <transaction>none</transaction>.

Here is some stripped-down code minus things like error handling, try/catch, rollbacks, etc.:

UserTransaction trxDelete = serviceRegistry.getTransactionService().getNonPropagatingUserTransaction(false);         trxDelete.begin();
retBi = deleteBundle(bundleId);
trxDelete.commit();

UserTransaction trxCreate = serviceRegistry.getTransactionService().getNonPropagatingUserTransaction(false);         trxCreate.begin();
retBi = createBundle(bundleId, bundleInfo.getBundledSubmissions());
trxCreate.commit();

createBundle() does the search on bundleId before creating the node, and is finding the deleted node IFF I don't run in the debugger. If run in the debugger, it doesn't find the deleted node. This makes me think that the commit is taking some time to actually complete and is returning before it's complete.

What is the best way to handle this situation?

Thanks,
Bill
2 REPLIES 2

mrogers
Star Contributor
Star Contributor
Your code would seem to be O.K. but there's some devil in the detail.   In particular you havn't said how your search within createBundle is working.

It would be better if you could avoid the two transactions and the use of the raw transaction handling.   

But the bottom line is it should work.

billhole
Champ in-the-making
Champ in-the-making
Thanks for the validation of that code. I found an Alfresco programmer on another team and he has a logical theory. The search is using Lucene/Solr. He thinks the Solr index is refreshed outside of the transaction, so the search was fetching stale data. I wrote a simplified create function that creates the new node without first searching for it, and everything is working fine now.

Thanks,
Bill