Hi guys,

I'm moving this thread to dev.

I have sent to Jan the mail where Selcuk was exposing the modifications done in JDBM so that JDBM3 can be made compatible with what we need. Here is Jan's response.

 So looking at this consistency of the tree is guaranteed by a
 reader/writer lock which is nice but browser keeps a read lock as long
 as it is open. So if we ever have a cursor which holds an underlying
 browser open and we try to modify the tree(which happens), then we
 will deadlock."


Cursor (Iterator) does not hold lock. It only locks tree for short
moment while fetching previous/next item.

JDBM3 have fail fast iterators as normal java collections. So there is
structural modification counter increased on each write/delete.

In previous scenario (open iterator and add an item while iterating) you
will not get deadlock, but 'ConcurrentModificationException' thrown from
iterator methods.

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/ConcurrentModificationException.html

I guess this can be solved with MVCC.

Regards,
Jan Kotek


Reply via email to