
|
If you were logged in you would be able to see more operations.
|
|
|
db4o Core
Created: 19/May/08 08:23 AM
Updated: 17/Jul/08 04:01 PM
|
|
| Component/s: |
None
|
| Affects Version/s: |
6.4.32
|
| Fix Version/s: |
7.3.45
|
|
|
Time Tracking:
|
|
Original Estimate:
|
Not Specified
|
|
|
Remaining Estimate:
|
0h
|
|
|
Time Spent:
|
31.67h
|
|
|
|
|
Environment:
|
Linux (debian etch). Using the 1.4 jar.
|
|
|
Testing db4o in bsh, with a view to using it in Freenet. We create a database, and write to it, and restart, it works. Then we deliberately fill up the disk (in another shell), and try to write to the database. db4o throws an Db4oIOException caused by out of disk space, but when we restart it, even if we remove the bigfile occupying all the disk space, we get an IncompatibleFileFormatException.
I have personally tried this with 6.4, a coworker tried it with 7.3, same result except different exception (IncompatibleFileFormat or InvalidSlot).
I know this is a case of deliberately breaking it to see if it still works ... but it ought to work, an embedded database included with an end-user application will frequently run up against temporary out of disk space conditions, it should recover gracefully (as Perst does for example).
|
|
Description
|
Testing db4o in bsh, with a view to using it in Freenet. We create a database, and write to it, and restart, it works. Then we deliberately fill up the disk (in another shell), and try to write to the database. db4o throws an Db4oIOException caused by out of disk space, but when we restart it, even if we remove the bigfile occupying all the disk space, we get an IncompatibleFileFormatException.
I have personally tried this with 6.4, a coworker tried it with 7.3, same result except different exception (IncompatibleFileFormat or InvalidSlot).
I know this is a case of deliberately breaking it to see if it still works ... but it ought to work, an embedded database included with an end-user application will frequently run up against temporary out of disk space conditions, it should recover gracefully (as Perst does for example). |
Show » |
|
The culprit in this case seems to be the CachedIoAdapter which is enabled by default - perhaps this decision should be reconsidered. As a workaround for the time being, explicitly running without the CachedIoAdapter should recover gracefully with all the data stored up to the last commit.
config.io(new RandomAccessFileAdapter()); // no CachedIoAdapter
While looking into it, we also have found some minor issues with graceful recovery from I/O failures, like not releasing the file lock unconditionally. Fixes will be checked in.