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.

and SERIALIZABLE transaction levels.
However at a lower level (READ_UNCOMMITED), the problem
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
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

View raw message