nassim-git / project-voldemort

Automatically exported from code.google.com/p/project-voldemort
Apache License 2.0
0 stars 0 forks source link

truncate() failing for bdbStorageEngine. #186

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Truncate feature was added in AdminClient and pushed to trunk, I realized 
after pushing that truncate() for bdbStorageEngine is failing, 
(BdbStorageEngineTest fails for testTruncate() with a DeadLockException 
https://gist.github.com/daf1bfb400e807544d24) 

Looking into the berkeley db documentation we need to close all open 
databases before truncating a database. 

Original issue reported on code.google.com by bbansal....@gmail.com on 5 Jan 2010 at 12:55

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Bhupesh, what's the status on this?

Original comment by kirktrue.im@gmail.com on 18 Nov 2010 at 7:01