Re: JDBC persistence

Martin Matula wrote:
> Please let me know as soon as you sign the JCA and your name appears on 
> the list.

I sent the JCA in today by snail mail, so it'll probably be a few days. 
  Below are some followups on some of your responses; I'll use the other 
answers to resolve some of my TODO's.  When you get time, let me know 
what you think about the first list under "Limitations and Unresolved 
Issues" (e.g. MOFID's and caching for non-primary indexes).

> 2) I wasn't clear on the semantics of unique-valued MultivaluedIndexes, 
> and memoryimpl and btreeimpl didn't provide a consistent answer. The MOF 
> boot sequence resulted in some attempts to insert duplicates.
> 
> [MaM] That's strage - bootmof should not create unique-valued indexes. 
> If it is really the case, it is probably a bug in MDR and we should 
> investigate it. But currently it is of low priority.

OK.  It's easy to reproduce by turning off the duplicate suppression 
code in JdbcMultivaluedIndex.add.  What should the semantics be (outside 
of bootmof)?  Store duplicates, discard duplicates, or throw an exception?


> 4) I did not implement keySet() and values() for JdbcPrimaryIndex 
> because in my testing I never saw them get called. Nor did I implement 
> queryByKeyPrefix() for any of the indexes, or fail-fast iterators anywhere.
> 
> [MaM] This may be a problem. In some of our internal project containing 
> custom implementations of JMI object we are touching some of these 
> methods (e.g. queryByKeyPrefix). However, it is up to you to decide 
> whether you want or do not want to implement it. I agree that these 
> methods will probably not be used in 99.9% of MDR clients.

They're all pretty easy to implement for everything except the primary 
index, where combining the cache contents with the contents of the 
database requires some extra work.


> 5) Due to (I'm guessing) an oversight, MDRCache.replace() is not public 
> as it should be. To work around this, I injected {@link 
> org.netbeans.mdr.persistence.btreeimpl.btreestorage.AccessHack} to sneak 
> in the required access.
> 
> [MaM] I don't think this was an oversight. MDRCache was not written with 
> goal of building a general purpose cache for different storages in mind. 
> It is an implementation specific thing of b-tree storage. There are 
> probably several things that could be factored out of the b-tree storage 
> into some kind of a storage-independent utilities. We are open to that 
> if it does not break anything or does not have a negative effect on 
> performance.

The reason I thought it was an oversight is that all of the other 
methods I needed are marked as public, and all of the internal methods 
which I shouldn't be using are private.  replace is the only method with 
package access.

Anyway, I totally agree about the importance of stability and 
performance, so any non-trivial refactoring would have to be undertaken 
carefully, with thorough review and testing.

JVS