Re: [Bacula-devel] RE: optimizing bacula

[Martin S. <ma...@xa...>]

>>>>> On Tue, 30 Nov 2004 10:31:19 -0500, Daniel Widyono <wi...@se...> said:

  >> try the insert first, if it works, done
  >> if it fails, do the update
  >> 
  >> the only time you would need to lock this one with transactions is if it
  >> is possible for deletes to happen between the insert and update. With this
  >> logic, you have reduced the average interactions to 1.5 instead of 4
  >> assuming the odds of a row already existing are 50/50. Even with the
  >> delete caveat, if the update failed, the dbms would still be in the same
  >> state as if the delete had happened a fraction of a second later anyway.
  >> 
  >> 
  >> Does this make sense at all to anyone else but me ?

  Dan> It does to my naive eyes.  However, there is the remaining problem (if at
  Dan> all) of delete happening before the insert.  Not a problem to the inserting
  Dan> process, but instead to the process which now assumes the delete succeeded
  Dan> and that row no longer exists.

  Dan> Yes?

Right, there is an higher level of locking that isn't addressed at all in the
current code, but luckily the filename and path tables are never cleaned of
stale entries automatically, so delete won't be a problem there.

Of course a foolish admin might purge a tape while it is being written :-)

__Martin