db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mo Maison <momai...@yahoo.fr>
Subject Re: insert, select --> deadlock (2 threads, 1 table)
Date Sun, 04 Jul 2010 07:17:37 GMT
Le 26/06/2010 22:25, Bryan Pendleton a écrit :
>> Now, I have remarked that creating an index on column 'SOMEDATA'
>> is sufficient to remove the deadlock.
>
> I think an alternate approach would be to commit the insert, then
> perform the select in a separate transaction.

This is not an option of course : all queries must be performed
in the same transaction in case rollback would be needed at a
later time.

>
> And yet a third way, I believe, would be to set your transaction
> isolation to a lower level than SERIALIZABLE.

Deadlock appears at READ_COMMITED, REPEATABLE_READ
and SERIALIZABLE transaction levels.
However at a lower level (READ_UNCOMMITED), the problem
disappears.
Again, this is not an option for me.

>
> But creating an index on the other column seems best, if you are
> routinely using it in the WHERE clause.

OK, that solves my problem for now, but my test can easily be
generalized.
For example, each thread can do an INSERT, followed by a SELECT
without any criteria (say, to display the whole table data after a
new data has been inserted -- I checked that the deadlock still
appears in this case).

I am surprised that this basic use case results in a deadlock.
Should I fill a bug report ?

Thanks for your answers,

   M. Maison



Mime
View raw message