[samba-tng] spoolss conversion and others

[Nicolas Williams]

On Sat Jan 29 2000, Luke Kenneth Casson Leighton wrote:
> On Fri, 28 Jan 2000, Peter Svensson wrote: 
> 
> > By switching to a real database (I assume that is what is being done, I 
> > was too quick with the "D"elete at the beginning of the thread) queuing up 
> > the incoming changes should be doable if we don't want to stall them 
> > until the unthrottle. 
> 
> weelll..... that's a bit of a pain. by "locking" you will stop EVERYONE 
> from being able to log in, access new shares etc. 
> 
> it's a bit like shutting off the pdc! 

Why? Use separate TDBs for SAM, WINs, shares. You've already stated that
the DCE/RPC daemons are single-threaded and will continue to be so for a
while. So if each DCE/RPC daemon has its own TDB locking those during
transaction commits cannot impact any services. Or did you mean that a
sysadmin locking a TDB could cause services to hang for the duration of
the sysadmin's transaction. Hmmm.

Just say "caveat emptor"! :^)

It shan't be your problem!

But if you really want to avoid that make TDB locking not lock out TDB
queries, use a transaction logfile to store all write operations and
truly commit them to the TDB at TDB unlock time. Unlocking would briefly
lock out TDB queries, sure, but the length of that lockout would be very
short, whereas a sysadmin might inadvertently keep writes locked out for
a long time.

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.