db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ace Jayz <fourtl...@gmail.com>
Subject Re: Atomic check for row existence and insert if doesn't exist
Date Mon, 12 Feb 2007 17:50:22 GMT

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?

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.

View raw message