Comments on: Bring Back the Hobgoblin: Dealing with RowInconsistentException

By: Fahad Ansari

Fahad Ansari — Wed, 28 Oct 2009 17:46:31 +0000

Nice post. I just wanted to add another case and also if you set -Djbo.debugoutput=console then JBO outputs the attribute with values that failed the consistency check.

The case that I ran into had to do with TIMESTAMP column. Our DBA’s set the TIMESTAMP column in the database with precision (0). So whenever we set the value from jbo the row became inconsistent right away because in the database it set milliseconds as 0 because of precision.

Of course, the refresh flag did not help in this case because this was a history column and history columns cannot have refresh flags set to true.

By: tilemahos

tilemahos — Mon, 08 Sep 2008 09:14:41 +0000

oh right, it’s that lost update thing. I think your suggestion is resonable.

By: Avrom

Avrom — Sun, 07 Sep 2008 20:42:14 +0000

Well, accorting to John Stegeman (http://stegemanoracle.blogspot.com/), whom I trust highly, this is simply part of the behavior or lock(). I’m still inclined to stand by my claim that known or not, it’s a bug–data loss protection should not be nearly so easily overcome. The best I can suggest, then, is to combine the diagnostic and locking code I suggested above: In case of a RowInconsistentException, check this row and its composed children for genuine inconsistencies, and either throw the exception or simply re-call lock() depending on whether you find a real inconsistency or not.

By: Avrom

Avrom — Fri, 05 Sep 2008 21:02:15 +0000

So, I’ve isolated the problem, and it looks to me (although I could be wrong) like a bug in lock()–if you call lock() twice on the same entity, it *always* succeeds the second time, even if the inconsistency problems haven’t been solved. I’ve started a thread on OTN about this:

http://forums.oracle.com/forums/thread.jspa?threadID=703011&tstart=0

I’ll post here about it when I have some more information, as well.

By: Avrom

Avrom — Fri, 05 Sep 2008 17:30:06 +0000

I’ve duplicated your issue. I’m looking into it right now.

By: tilemahos

tilemahos — Fri, 05 Sep 2008 14:47:10 +0000

yes i change the same row, if you give it a try yourself please let me know of the result

thanks
Tilemahos

By: Avrom

Avrom — Fri, 05 Sep 2008 14:21:21 +0000

Thanks for your additional example.

I’m a bit curious about your second case. Does it actually prevent JBO-25014 for you if someone has changed *the same row* that has been changed in this transaction? REFRESH_WITH_DB_ONLY_IF_UNCHANGED should have no effect on rows that have been changed within the transaction.

By: tilemahos

tilemahos — Fri, 05 Sep 2008 07:15:36 +0000

I also want to add another case similar to the case no 1 you mentioned. A field that is marked as refresh after appers after update/insert having null value and of course JBO-25014 is here again.
This is happening in case that the field is being mentioned in the trigger but is value is not set. This is happening due to an update .. returning bug see http://forums.oracle.com/forums/message.jspa?messageID=2740885

for more info

By the way, i run your code and i think that the instruction
refresh(REFRESH_WITH_DB_ONLY_IF_UNCHANGED | REFRESH_CONTAINEES);
prevents the appearance of JBO-25014 even if really someone change the row in between!

Tilemahos