wfalby wrote:
My application processes events. These events are sent to registered users.
These events can be deleted when they reach a certain age. There is a thread
to send events to registered users and there is another thread to delete old
events. The thread sending an event should lock it from the thread that
deletes old events. Each thread uses its own connection to the database. In
the sending thread, I've tried using a SELECT ... FOR UPDATE and setting the
ResultSet.CONCUR_UPDATABLE on the prepare statement. In both cases, the
thread that deletes events deleted the event being held by the sending
thread. The default isolation level and autocommit options are used.
Hi Walter,
If you're using the read committed isolation level, I think you need to
use SELECT ... FOR UPDATE WITH RS.
Which behavior do you see if you do that?
I think Derby treats SELECT ... FOR UPDATE a bit differently than some
other database systems, and I also believe there is at least one Jira
[1] issue logged for changing the behavior.
Regards,
--
Kristian
[1] https://issues.apache.org/jira/browse/DERBY
Thanks in advance...Walter
