Subject: [ldapext] Questions / comments about "LDAP Transactions, draft-zeilenga-ldap-txn-11.txt"

From: Christian Hollstein <[email-masked]>
Date: Sat, 26 Apr 2008 21:43:08 +0200

Hello!

I have some questions:

According to the draft it is not forbidden, that a client sends non - 
transaction update requests or read - only (compare, search) requests on 
the same connection, after having started the transaction. These 
requests, that don't belong to the transaction (because they don't carry 
the transaction control) could conflict with requests, that are part of 
the transaction. Just imagine the transaction updating some entries, 
that are meanwhile processed in a subtree search. How should the server 
deal with this? Should it process the non - transaction requests after 
having finished the transaction? After having received the commit from 
the client? If non - transaction updates may be mixed with updates, that 
are part of the transaction you either violate the required atomicity, 
or you have to postpone the non - transaction request until the 
transaction is finished, thereby violating the correct order of requests.

Christian
_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: Howard Chu <[email-masked]>
Date: Sat, 26 Apr 2008 17:47:49 -0700

> transaction is finished, thereby violating the correct order of requests.

I don't see any conflict. The requests that are part of the transaction don't 
actually take any effect until the Commit request is received.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ldapext

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 27 Apr 2008 06:50:16 -0700

On Apr 26, 2008, at 12:43 PM, Christian Hollstein wrote:

> the same connection, after having started the transaction.

Yes, and expected behavior is similar to that when a client sends a  
read (compare,search)
requests on the same (or different) connection before/after starting a  
modify entry operation.
The modify entry operation provides ACID properties.  So does the  
transaction.

> These
> deal with this?

Anyway that provides ACID properties.

> Should it process the non - transaction requests after

LDAP does not generally require DSAs to process operations in any  
particular order, so nothing to violate.