On Mon, 2006-06-19 at 14:47 +0200, Marcel Reutegger wrote: > There are two reason why this can happen (as far as I can see): > > - the session actually did modify the node /counter before calling > generateNewResourceId(), thus it cannot lock the node > > or > > - a previous call to generateNewResourceId() failed in the > Locked.run() method, leaving unsaved changes. > The Locked utility does not automatically revert changes in case of an > exception thrown by Locked.run(). That's the responsibility of the > caller, because only he knows what is actually done in Locked.run(). > > The code you provided only shows the Locked.run() method, but does not > include a test case that shows how and when generateNewResourceId() is > called. Do you have a simple test that reproduces the > InvalidItemStateException?
Hmm, it's a bit difficult as I'd have to rip it out of the framework.. I'll put something simple together. > One other question: does this happen always > or only sporadically? It happens all the time. Would it be correct to call refresh(false) on the counter node in case of an exception? I only ever modify the value property when the node is created and in the generateNewResourceId() method. -- Torgeir Veimo <[EMAIL PROTECTED]>
