franferta / jdbm2

Automatically exported from code.google.com/p/jdbm2
0 stars 0 forks source link

HashBucket.writeExternal is destructive when HTree has a custom key serializer #7

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Run the attached junit test case

What is the expected output? What do you see instead?

Expected: Junit test succeeds.

Actual: ClassCastException stating that a byte array cannot be cast to Long.

java.lang.ClassCastException: [B cannot be cast to java.lang.Long
    at jdbm.htree.TestInsertUpdate$1.serialize(TestInsertUpdate.java:1)
    at jdbm.htree.HashBucket.writeExternal(HashBucket.java:225)
    at jdbm.htree.HTree$1.serialize(HTree.java:70)
    at jdbm.htree.HTree$1.serialize(HTree.java:1)
    at jdbm.recman.BaseRecordManager.update2(BaseRecordManager.java:466)
    at jdbm.recman.BaseRecordManager.update(BaseRecordManager.java:452)
    at jdbm.recman.CacheRecordManager.updateCacheEntries(CacheRecordManager.java:323)
    at jdbm.recman.CacheRecordManager.commit(CacheRecordManager.java:255)
    at jdbm.htree.TestInsertUpdate.testInsertUpdateWithCustomSerializer(TestInsertUpdate.java:39)
    at 
...
(more traces from the JUnit4 framework, run within Eclipse Indigo)

What version of the product are you using? On what operating system?

JDBM2.1, running in Eclipse Indigo, Windows

Please provide any additional information below.

The exception is caused by HashBucket.writeExternal modifying keys in-place if 
a custom key serializer is used. After serialization with a custom key 
serializer, this._keys no longer contains the keys but the serialized keys as 
byte arrays.

The attached file HashBucket.java provides a fix for this bug.

Original issue reported on code.google.com by t.wolf...@gmail.com on 7 Jun 2011 at 1:12

Attachments:

GoogleCodeExporter commented 8 years ago
Note that the proposed fix changes the external storage layout and will 
therefore be incompatible with databases written by previous versions. For use 
in the distributed version of JDBM2, I'd suggest to write a non-destructive 
serialization that does preserve binary compatibility. In the simplest case, 
just use a copy of this._keys in writeExternal() instead of using an object 
assignment; though allocating a new (copied) list may not be the most efficient 
way.

Original comment by t.wolf...@gmail.com on 7 Jun 2011 at 2:24

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r79.

Original comment by kja...@gmail.com on 4 Sep 2011 at 5:53

GoogleCodeExporter commented 8 years ago
I used other solution. If key is 'byte[]' it assumes that custom serializer is 
used and tries to use it. 

Fixed in revision 79

Original comment by kja...@gmail.com on 4 Sep 2011 at 5:54