Typo, I meant "pseudo concurrent" thread, not "spsudo concurrent"...

Jeff

--- In firebird-support@yahoogroups.com, "Jeff Lynn" <jmlynn@...> wrote:
>
> I read from your post that once the "Begin backup" was executed,
> whatever thread wants to insert a record into the database will be
> blocked until the "End backup" was executed.
>
> May be I am a bit on the safe side, I used semaphore to allow one of
> many threads to update the database table to track what files had been
> processed based on what IP or UNC path the file originated, file size,
> and last write time. My daemon process forks a thread for each type
> of files to be monitored for file processing from one of houndreds of
> business partners that send files to me. I added database tracking
> using Firebird so I know if the same file become "sticky" due to
> various reason that the daemon process was not able to delete/rename
> after pulling if down from the remote FTP Server.
>
> So from you post, are you stating that "spsudo concurrent" threads
> each inserting record to the same table of the embedded FB database
> file is safe without a need to synchronize their access?
>
> Jeff
>
>
> --- In firebird-support@yahoogroups.com, "Ivan Prenosil"
> <Ivan.Prenosil@> wrote:
> >
> > > So from Ivan's post, it seems that if my management thread gain
> > > exclusive access to the database by gaining the semaphore first,
> > > followed by excuting the "ALTER DATABASE BEGIN BACKUP" SQL before
> > > start file copy, and executes the "ALTER DATABASE END BACKUP" will
> > > address the problem of having the backed up copy of the database
file
> > > being corrupted.
> >
> > You do not need any semaphore. While the database is locked by
> "ALTER DATABASE
> > BEGIN BACKUP" the Firebird will not touch the db file, but you do
> not need
> > to interrupt your work with that db because all changes are sent to
> temporary file.
> >
> > Ivan
> >
>