Le 20/09/2018 à 14:57, Howard Chu a écrit : > Emmanuel Lécharny wrote: >> >> >> Le 20/09/2018 à 14:18, Howard Chu a écrit : >>> Emmanuel Lécharny wrote: >>>> Hi ! >>>> Now, there is more work to do : >>>> o rollback hasn't been tested yet >>>> o we need to forbid concurrent writes while a transaction is being >>>> executed - which means that a transaction is seen as one single giant >>>> write - with the consequence that a rogue client starting a transaction >>>> but never finishing it will potentially lock the server. >>>> o a mechanism to protect the server against such rogues client has to be >>>> implemented (could be a limitation in the number of update per >>>> transaction and/or a time limit for a transaction). >>> >>> In OpenLDAP we simply queue the incoming ops until the Commit is received, >>> then execute them all at once. And yes, there's a limit on the number of >>> ops allowed in a txn. >> >> >> In ApacheDS, that would not save a lot of CPU/time, as the work is done >> when updates are injected in the in-memory pages and flushed on disk. >> Stacking them and injecting them in one shot will not save anything. > > This isn't meant as a performance optimization, it's about error handling. > It's to prevent transactions from keeping the DB locked for long times while > the client is sending operations. This way we only start writing a txn to a DB > when we know all of its ops are already present and we don't need to > worry about the client timing out in the middle.
Understood. Typically useful if the client sends a endTransaction with the commit flag set to false. Sounds like a smart way to deal with this use case. Thanks for the trick ! -- Emmanuel Lecharny Symas.com directory.apache.org
pEpkey.asc
Description: application/pgp-keys
