Ace Jayz wrote: > > > If REPEATABLE READ is in effect, then no other transaction would be able > to delete the row between the insert and the select because this would > result in > different results for the select statement if it were repeated. For > example, the first execution of the select might return a row (if it > existed) but a second execution > of the same select statement might return 0 results if a delete was > allowed to sneak in before the select was executed. Is this correct? > > Thanks, > Ace. >
I'm going to correct myself here and say that SERIALIZABLE would probably be the right choice in this case, since REPEATABLE READ won't prevent phantoms. I was trying to avoid SERIALIZABLE if possible to increase concurrency, but I don't think I have a choice in this case. Is there any way to avoid SERIALIZABLE in this case or is using it in a short transaction with my requirements acceptable? Ace. -- View this message in context: http://www.nabble.com/Atomic-check-for-row-existence-and-insert-if-doesn%27t-exist-tf3204425.html#a8929119 Sent from the Apache Derby Users mailing list archive at Nabble.com.
