[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Write-intensive LDAP

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Booker C.
> Bense

> On 17 Sep 2002, Tony Earnshaw wrote:
>
> > tir, 2002-09-17 kl. 19:42 skrev Booker C. Bense:
> >
> > > - Read the protocol more closely. There is no support for transactions
> > > or locking. You will have a hard time building a robust system with
> > > lot's of writes without those primatives. Any system that writes
> > > extensively to LDAP needs to support a complete rollback/queueing
> > > implementation outside of the protocol. Speed is not the problem,
> > > consistancy is what will bite you in the long run. LDAP works fine
> > > for WIRM applications ( write infrequently read many), it breaks
> > > horribly for write intensive applications.
> >
> > This hasn't got much to do with the protocol IMHO, everything to do with
> > the choice of database. BDB 4.0.14 does, indeed, have fine-grained
> > locking and transactional (roll-back) logging.

> - The problem is not consistancy of the database in current software,
>   it's consistancy of the information. There's no way for your
>   application to have any guarantee that the data it reads back,
>   is the data it's written. If that's not a requirement of the
>   application then ldap may be perfectly acceptable.

NFS doesn't provide this sort of guarantee either, but people manage to get
by with it. The whole "last-writer-wins" philosophy has been part of Unix
since the Beginning of Time. If you update an entry and then someone else
updates the entry 5 msec later, and then you read the entry, certainly you
won't see the data you just wrote. If you need some other kind of behavior
you can implement it at your application level. Of course, if you have an app
that immediately re-reads what it just wrote, I think there's something
broken in your app's design; it ought to know what it wrote without
re-reading it.

For a work-flow manager, you can do just fine with LDAP. Updates only occur
when a work item progresses past a certain point in the flow, they are not
arbitrary changes and it makes no sense to perform them out of order. As
such, a simple "state" attribute is all that's needed to handle things. It
takes two operations to update the state: one to read the current value, and
one to atomically set the entry into the next state:

(ldapsearch):  state=xxx
(ldapmodify):
	changetype: modify
	delete: state
	state: xxx
	-
	add: state
	state: yyy
	-

If the modify fails, then someone else updated the entry's state... The logic
to manage this is trivial.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support