Re: account balances

["Ryurick M. Hristev" <ryurick.hristev@canterbury.ac.nz>]

On Sun, 24 Nov 2002, Tony Earnshaw wrote:

> søn, 2002-11-24 kl. 20:36 skrev Ryurick M. Hristev:
> 
> > > 4: IMHO, anyone who puts cash balances in a replicable,
> > > organization-wide directory database with absolutely no guarantee of
> > > concurrency needs an immediate trip to the shrink.
> > 
> > Unless there is my case where I have just to update once a day
> > the balance from upstream and only be able to read it, not update it. 
> > 
> > Second: it doesn't have to be _maintained_ by the ldap server,
> > just to be _read_! I.e. I assume one could have a DB in the backend
> > and use LDAP just to _read_ the values. But in order to be able
> > to read the values trough the LDAP protocol it must have a schema
> > entry somewhere. At least this is my understanding.
> > 
> > Third: in a "one master, several slaves" only the masted may be
> > allowed to update the records so the problem of write concurrency
> > does not exists.
> 
> > Could somebody tell me please if I am wrong and why ?
> 
> I have a balance of a million Euros at my bank (or anywhere). My bank
> (or anyone) uses an ldap master and 3 slaves somewhere else in the
> country. I take out 999,999 Euros and immediately arrange for the master
> to crash. I go to another bank that uses my bank's ldapserver for its
> account data, but because the master is down, it gets its data from one
> of the slaves. I then take out another 999,999 Euros. I've arranged for
> that slave to crash too ...
> 
> People who look after other peoples' money just do not put any account
> details in ldap directory servers.

IMHO your example is flawed. Never mind that we are talking about
_computer_ accounts not _bank_ accounts but:

What you are doing there is a _transaction_. I doubt that anyone
in its own mind would use anything else in the situation you describe.
I.e. your withdrawal will either go all way trough or not at all.
This is the main reason transactions have been invented in the
first place: to make operations atomic.

I would say that it should be possible to have a transactional
DB in the backend and LDAP in the frontend if this is what you want.
I.e. you connect to your DB via an LDAP interface.

Your example is just an example of poor architectural design,
nothing else. Using just a DB (and avoiding LDAP) won't
stop you from shooting yourself in the proverbial foot :-)
if you are not careful anyway. In your example, a more appropriate
way would be to use several ldap servers connecting to the same
transactional DB backend in which case crashing one LDAP server
will lead to nothing.

Again, yes you may want to use a DB backend to store values but
I don't see why you shouldn't be able to access the values trough
the LDAP protocol, in which case you need to have it into the schema. 

Sorry, I am not convinced.

Cheers,
-- 
Ryurick M. Hristev mailto:ryurick.hristev@canterbury.ac.nz
Computer Systems Manager
University of Canterbury, Physics & Astronomy Dept., New Zealand