Open GoogleCodeExporter opened 9 years ago
Test is now passing with this change:
http://github.com/Omega1/voldemort/blob/master/src/java/voldemort/store/bdb/BdbS
torageE
ngine.java
Original comment by bruce.ri...@gmail.com
on 5 Jan 2010 at 4:30
I made somewhat simpler changes , please take a look.
http://github.com/bbansal/voldemort/commit/16a7fced92d9fa00fcf63a6c00f450b756e3e
d21
Original comment by bbansal....@gmail.com
on 5 Jan 2010 at 10:02
The only real issue I have with the difference in our proposed changes is I'm
not sure
I like that any concurrent operation to a truncate call will start throwing
exceptions
- even any that happen to have started prior to the call to truncate. It's not
my call
but as a user of the system that might throw me off a bit.
Original comment by bruce.ri...@gmail.com
on 6 Jan 2010 at 5:43
Any concurrent operation while truncating() will give you bad/inconsistent data
(null/older version) Berkeley db folks recommend closing all open databases
while
truncating.
I dont think we can/should serve concurrent operation while truncating()
Original comment by bbansal....@gmail.com
on 6 Jan 2010 at 9:57
I agree that concurrent operations while truncating is a bad idea - it's just
the
method we choose to fulfill that requirement that we differ on. I was using a
read/write lock to wait for existing requests to finish and stall new requests
until
the truncate is completed whereas your proposal will return immediately - just
with an
exception. Choose your poison - stalled requests or immediate returns with
exceptions.
Original comment by bruce.ri...@gmail.com
on 7 Jan 2010 at 4:23
So, what is the decision in the end? Are there plans to stall the requests
while the
truncation is taking place or will it remain like this?
Original comment by ismaelj
on 3 Feb 2010 at 9:16
Bhupesh, what's the status on this?
Original comment by kirktrue.im@gmail.com
on 18 Nov 2010 at 7:01
Original issue reported on code.google.com by
bbansal....@gmail.com
on 5 Jan 2010 at 12:55