[Jdbm-general] Re: Jdbm-general digest, Vol 1 #27 - 1 msg

[<dhe...@ya...>]

Hello ...

I started  porting the TreeMap classe on top of a Container/RecordManager
abstraction ...
It looks good ...
A simple question before debuging :-) : what is the status of the SUN code:
are we authorized to use it   ... ?
Anyway, performance on sorted indexes on a persistent array list are not so
bad : binary search on a 100 000 records file is less than 1ms !!! I am not
sure that TreeMap will achieve such perf. TreeMap (or RedBlack Binary Trees)

Daniel HERLEMONT

----- Original Message -----
From: <jdb...@li...>
To: <jdb...@li...>
Sent: Saturday, April 07, 2001 9:02 PM
Subject: Jdbm-general digest, Vol 1 #27 - 1 msg


> Send Jdbm-general mailing list submissions to
> jdb...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.sourceforge.net/lists/listinfo/jdbm-general
> or, via email, send a message with subject or body 'help' to
> jdb...@li...
>
> You can reach the person managing the list at
> jdb...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Jdbm-general digest..."
>
>
> Today's Topics:
>
>    1. Re: Jdbm-general digest, Vol 1 #26 - 5 msgs (dhe...@ya...)
>
> --__--__--
>
> Message: 1
> From: dhe...@ya...
> Reply-To: <dhe...@ya...>
> To: <jdb...@li...>
> Date: Fri, 6 Apr 2001 23:11:53 +0200
> Organization: YATS
> Subject: [Jdbm-general] Re: Jdbm-general digest, Vol 1 #26 - 5 msgs
>
>
> Hi Alex,
>
> > I was planning on offering a similar interface to your Container
> > interface on top of JDBM to support BLOBs (with a big L).
>
> Yes this is exactly what I meant. your BLOB = my Container .. and I would
be
> very nice to have it
> within JDBM.
>
> >
> > Although your interface is a nice abstraction for any random access
> > device, I don't think it would be the best approach for implementing
> > collections on JDBM.  The reason being that the collection would have to
> > do their own space allocation management.  JDBM already provides
> > allocation management and the main API abstracts this:
>
> true ...
> I also define an Allocator interface with 2 methods :
> byte[] alloc(size), and free(address,size) (where addresses and size could
> be different from the allocated ones)
>
> Such allocator could be implemented on a Container in different manner
> starting from the most stupid one, that consist in appending newly
allocated
> block, and never freeing blocks, and do reorg from time to time ... up to
> best technics like buddy system, best fit, etc, ...
> but even  stupid method are quite effective, and could be usefull in many
> situations :  "temporary" persistent collections,
> like databases caches,  provide a swapping facility for big memory
> collections ... append only collections like a stock quotes  file, emails,
> ... many applications are apend only, ... and sometime its even
interestingg
> to have access to previous version -
> BTW do you considering versionning (I have some ideas on that ... )
>
>
> >
> > // summary of related methods
> > class RecordManager {
> >
> >     long insert(byte[] data);
> >
> >     byte[] fetchByteArray(long recid);
> >
> >     void update(long recid, byte[] data);
> > }
>
> Yes this is very nice. And could provide a good basis to implement simple
> collections like ArrayList, consisting, maybe in a list of recids. BTW,
such
> indirection could be nice to implement very efficient sorting, whithout
> moving the objects ...  the question is how to represent this directory of
> recid ? maybe into an other recid or a tree of recids .. but you have
> already implement more complex things for the hashtable ..
> BTW it should be easy to implement an ArrayList on your recman, by
extending
> AbstractArrayList and implement only some few method, like size(), get,
> set/add(index,object) and remove(index) tht all .. and you get all the
> Colleciton Framewrok with iterators, sorting, .... (but the SUN sorting is
> not appropriate since they copy the List into memory ... sorting should be
> implemented in a different way) ... so we have to know how Collection
> methods are implemented before applying them to the persistent case. BTW,
It
> would be nice to implement an ODMG like DCollection, with union and
> intersection ...
>
>
> Just a question : is it possible to update part of  data block without
> copying all data, like
> update(recid, offset, byte[] data) ?
> and byte[] fetchByteArray(long recid, long offset, int size);
> Maybe is something like that when you speek of BLOB ?
> I don't know if this is making sense ? I don't know what is the status of
a
> recid: something between a memory address and (bytes) object identifier ?
>
>
>
> >
> > In short, we can implement your Container interface with JDBM but I
> > don't consider that this approach leverages JDBM's functionality in the
> > context of implementing collections.
>
> Sure ... my Container is much more basic than JDBM, I defined this beacuse
I
> didn't want to stick to a RandomAccessFile model ... and lett port the
> collecin on top of other models like JDBM :)
> BTW, I would not consider JDBM as a single and unique Container.
> I think JDBM is a good candidate to support multiple Containers, and
manage
> mutliples collections in a transactional environment ... for exemple, I
> would consider JDBM  for managing coupled Collections and indexes (like
> indexes of SQL tables), and perform updates within a transaction.
> Then I will be very happy ...  since I have too many pbs with sql DB : pb
of
> mapping, pb of performance, ...
> an other consideration would be the remote case ? but ...  why not to
> develop a RMI interface (or an EJB) + proxy  to your RecordManager
interface
> ... it could be usefull also.
>
> >
> > Do you have an abstraction such as the RecordManager in your collection
> > framework?  Or every collection does its own specialized allocation
> > management?
>
> This is the reason why I have not really implemented a true allocation
> strategy, and expect this stuff be provided by an other layer ... like
JDBM
> ;-)
>
>
>
> Daniel.
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> Jdbm-general mailing list
> Jdb...@li...
> http://lists.sourceforge.net/lists/listinfo/jdbm-general
>
>
> End of Jdbm-general Digest
>