I'm very interested in this DAS stuff.  Excuse me for not being too vocal about it which is
partly due to being ignorant about the topic and partly due to the fact that I fish every day these
days (still on vacation too).
Will try to keep up but Ole you're doing something great here.  I can't wait to see the results
when you're finished.
On 3/25/07, ole ersoy <ole.ersoy@gmail.com> wrote:
Hey Luciano,

I'm still in Canada visiting Inlaws, but I'm hoping to have a prototype ready soon after I get back (Wen Night).

Thanks for pointing us to the sandbox.

I think this DAS implementation should go pretty quick, since were storing each object on the server entirely in

After that we can experiment with using the change summary as well.  I'm thinking that when ADS gets a memory
resident backend (Prevayler type stuff), and if we store objects as  list of attributes and only update the
changed attributes, it will be ridiculously fast.

- Ole

On 3/24/07, Luciano Resende < luckbr1975@gmail.com > wrote:
I have started some infrastructure refactory to allow multiple DAS implementations in my sandbox in case you guys want proceed with some prototypes around this :


I'm not an expert on LDAP, but I can certainly help with DAS/SDO.

Luciano Resende

On 3/22/07, Emmanuel Lecharny <elecharny@gmail.com > wrote:
Ole Ersoy a écrit :

> Hey Guys,
> I just read my mail over again:
> ===========================================
> Just wanted to see if anyone had any thoughts on handling updates
> to Java beans (Service Data Objects - but basically the same thing)
> persisted with ADS.
> ===========================================
> I think instead of saying "Persisted with ADS",
> I should have said:
> "Using ADS as their persistance/storage solution"
> So for instance we might have an Eclipse App.
> The Eclipse App uses some Javabeans (SDOs) to store info.
> Then when the App needs to do a save, it would use the LDAP DAS
> to persist it's attributes and references  to ADS.
> ADS  would then persist this entry to whatever backend ADS uses.

Well, that's a totally different story then :)

You have to know that Ldap Server is able to store plain java objects,
so maybe you don't really need to store attributes one by one, nor to
declare a full new schema based on the object's memebers. Have a look at
http://www.faqs.org/rfcs/rfc2713.html. ADS implements this RFC. Doing so
will be at least an order of magnitude faster, I think.

> So the beans (SDOs) are writing to ADS.
> ADS then writes to its backend.
> Does that make more sense?

Yeah. ADS will be the backend. I think that doing a very simple
experiment is a matter of a few days, and I would be *very* interesting
if you could do such a test.

I just don't know if ADS could be fatser than a RDB to do that, if you
consider that ADS will be able to read around 400 req/s on a standard
computer (3Ghz, mono cpu)

Go for it, Ole !

> Thanks,
> - Ole