Skip to Main Content
Forums

Berkeley DB Family

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

JE intermediate changes

Greybird-OracleJul 28 2006 — edited Jul 28 2006
JE users,

The JE development team would like to make you aware of a set of changes that have been made since the 3.0.12 release. If these changes contain fixes that are important for you to obtain before the next major release, please send an email to support@sleepycat.com and we will send you the intermediate release. In particular, there have been several bug fixes to the Direct Persistence Layer beta release that may be helpful to you if you are DPL user. The list of changes is below.

To all who reported problems in the DPL beta release -- thank you!

Mark

General Environment Changes

1. When an Error (OutOfMemoryError, for example) is thrown during database operations, invalidate the Environment so that RunRecoveryException will be thrown if further operations are attempted. [#14300](3.0.36)

2. Fix a bug that caused a NullPointerException when Database.sync() was called on a newly created, empty deferred-write database. [#14781](3.0.20)

3. Fix a bug that caused a NullPointerException in the cleaner thread when running under a JDK1.6 beta. [#14877](3.0.36)

4. Added a new Environment configuration parameter: je.adler32.chunkSize. This may be configured to prevent OutOfMemoryError in some situations. The Java Adler32 algorithm, used by JE for checksumming, allocates direct memory. The amount of direct memory allocated at one time can be reduced by setting a chunk size. Note that Adler32 memory allocation is not known to cause OutOfMemory on Java 1.6, only on Java 1.5 and earlier. [#14149](3.0.36)

Direct Persistence Layer

1. Fix a bug that prevented opening a read-only store when a primary key sequence was used. [#14941](3.0.36)

2. Fix a bug that prevented using EntityJoin with read-uncommitted (for example, CursorConfig.READ_UNCOMMITTED). The fix is a change to JE secondary databases that allows a partial DatabaseEntry to be passed as the data parameter to a search method, when using read-uncommitted. [#14966] (3.0.36)

3. Fix a bug in EntityStore.getStoreNames() which resulted in this stack trace:
java.lang.StringIndexOutOfBoundsException: String index out of range: -9
at java.lang.String.substring(Unknown Source)
at com.sleepycat.persist.impl.Store.getStoreNames(Store.java:209)
at
com.sleepycat.persist.EntityStore.getStoreNames(EntityStore.java:186)
[#14978](3.0.36)

4. Fix a bug that caused an IllegalArgumentException when calling EntityStore.getSecondaryIndex for a @SecondaryKey that was declared on a superclass of the entity class. [#14978](3.0.36)

5. Also note that if @SecondaryKey is used on a field in a subclass of an entity class, EntityStore.getSecondaryIndex will currently fail. A fix for this problem will be in a subsequent release. A workaround is to register the class containing the secondary key before opening the store. For example:

/* Create the model explicitly and register the subclasses */
EntityModel model = new AnnotationModel();
model.registerClass(Manager.class);

/* Use the model to configure the store */
StoreConfig storeConfig = new StoreConfig();
storeConfig.setAllowCreate(true);
storeConfig.setModel(model);
EntityStore store = new EntityStore(..., storeConfig);

See also this newsgroup post describing the problem and a future fix: http://groups.google.com/group/comp.databases.berkeley-db/browse_thread/thread/3359a0c7d6cd6d25?hl=en

Comments

morgalr
958296 wrote:
Hello everyone,

I've got a few problems using WatchService.class:

public void watch() throws IOException, InterruptedException{
WatchService watchService = FileSystems.getDefault().newWatchService();

Paths.get(desktopDirPath).register(watchService,
StandardWatchEventKinds.ENTRY_CREATE,
StandardWatchEventKinds.ENTRY_DELETE,
StandardWatchEventKinds.ENTRY_MODIFY);

while(true){
WatchKey key = watchService.take();

for(WatchEvent<?> event : key.pollEvents()){
WatchEvent.Kind<?> kind = event.kind();

switch(kind.name()){
case KIND_ENTRY_CREATE:
// ... do something
break;
// ... more cases ...
default:
break;
}
}
key.reset();
}
}

So, there is my code snippet. First things first:

1.) Is a new thread started automatically when calling watchService's call method? I've been wondering because the method throws an InterruptedException.
Without actually checking the implementation, my understanding is that you have a thread created for he WatchService.
2.) I've got problems dealing with the watch events. For example let's imagine we want to move or delete one or more files when created in a specified directory. It seems to work for one file or even a few more. But it fails to handle new files which are created rapidly for example by a service in the watched directory. It seems that the occurring events aren't recognized fast enough, but that's just my theory. I've tried logging the paths to the files in a hashtable and deleting them asynchronous in another thread but it seems that I'll have to deal with concurrency then, won't I?
Yes. As stated in the WatchService Doc, actual functionality of the WatchService is highly platfom implementation specific, and the problem you list is one listed. Any time you have a file that may be visible by others, you have to deal with a potential concurrency issue.
1 - 1
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Aug 25 2006
Added on Jul 28 2006
#berkeley-db-java-edition
1 comment
1,328 views