directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ApacheDS] Partition design and interfaces
Date Wed, 16 Jan 2008 14:53:39 GMT
Hi all,

On Jan 16, 2008 5:26 AM, Emmanuel Lecharny <> wrote:

> Hi Alex, PAM,
> if we are to go away from JNDI, Option 2 is out of question. Anyway, the
> backend role is to store data, which has nothing in common with Naming,
> isn't it ?

Well if you mean the tables yes you're right it has little to do with
javax.naming except for one little thing that keeps pissing me off which is
the fact that normalization is needed by indices to function properly.  And
normalizers generate NamingExceptions.  If anyone has any idea on how best
to deal with this please let me know.

> More than that, we may have to build tools on top of this layer,

Yes good point I did not consider this however please take a look below how
I describe some of these layers.

> and I
> see no reason to depend on NamingException when we have nothing to do
> with LDAP.

We still have some residual dependence on LDAP at higher levels like when we
talk about Index or Partition because of the nature of their interfaces.
Partitions are still partial to the LDAP namespace or we would be screwed.
They still need to be tailored to the LDAP namespace.  There are in my mind
2 layers of abstractions and their interfaces which I should probably

Partition Abstraction Layer
  o layer between the server and the entry store/search engine (eventually
we might separate search from stores)
  o interfaces highly dependent on the LDAP namespace

BTree Partition Layer
  o layer between an abstract partition implementation with concrete search
engine which uses a concrete search engine based on a two column db design
backed by BTree (or similar primitive data structures)
  o moderately dependent on the namespace

Note the BTree Partition Layer is where we have interfaces defined like
Table, and Index.  These structures along with Cursors are to be used by
this default search engine to conduct search.  We can then swap out btree
implementations between in memory, JE and JDBM easily without messing with
the search algorithm.

> Option 1 will conflict in some way with JDBM and JE design, as stated by
> PAM.

Yeah you're right.

> I would favor Option 3 then.
> The good thing is that defining a new set of exceptions is not really
> that hard :)

Right and it is neutral to all implementations - just slightly more
repetitive work for me but no big deal.


> Pierre-Arnaud Marcelot wrote:
> > Hi Alex,
> >
> > Option 1 seems the easiest solution but will it work with an exception
> > based on DatabaseException ?
> > I don't think... Reading the JE API, DatabaseException extends
> > Exception and not IOException.
> >
> > I like Option 3 and the idea to encapsulate the exception thrown
> > inside our "own exception". But it means surely a lot of refactoring...
> >
> > My 2 cents. ;)
> >
> > Pierre-Arnaud
> >
> > On Jan 15, 2008 11:45 PM, Alex Karasulu <
> > <>> wrote:
> >
> >     Hi all,
> >
> >     Different underlying stores have different kinds of checked
> >     exceptions they throw at the lowest level.  For example JDBM is
> >     humble and just uses IO exceptions.  The JE authors use an
> >     exception hierarchy based on DatabaseException.  I was wondering
> >     if there was a preference out the base class for what exceptions
> >     are thrown from partitions?  Right now there are a few options:
> >
> >     (1) Throw exceptions that extend IOException (works well with JDBM)
> >     (2) Throw NamingExceptions works well with Java Naming but we have
> >     a bad taste in our mouths from this.
> >     (3) Create our own base class for exceptions thrown at these lower
> >     layers like say PartitionException
> >
> >     Right now I went with IOException but I'm thinking it might be
> >     biased towards a particular partition implementation.  Does anyone
> >     have some opinion one way or the other?
> >
> >     Alex
> >
> >
> >
> >
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message