John Forte writes: > David Powell wrote: > > John Forte wrote: > > > I have two processes updating a property group simultaneously, or > > > attempting to at least. Both transactions are started successfully. I > > > assume there are no restrictions in having two transactions started > > > against the same property group. The problem I have is that after one > > > process successfully commits, when the second process executes the > > > commit, the call to scf_transaction_commit appears to succeed but of > > > course there was no write to the database. I'm trying to understand > > > why an error is not set for the second commit. > > > > > > According to the manpage, it appears that there is no error for this > > > scenario. > > > > From scf_transaction_commit(3SCF): > > > > RETURN VALUES > > ... > > The scf_transaction_commit() function returns 1 upon suc- > > cessful commit, 0 if the property group set in > > scf_transaction_start() is not the most recent, and -1 on > > failure. > > > > How are you measuring success? > No doubt incorrectly due to not RTFM. For my purposes, It would appear > that I should be considering 0 and -1 a failure. I was measuring failure > as -1. I'm still a bit confused as to why a failed commit should not > return -1 (failure).
The original idea was that your while() loop for a failed commit which failed due to an out of date generation can be pretty tight, so it'd be nice to detect that differently than other failure conditions which may not be retried for many consumers. If that isn't true for your use case, you can just test for success rather than differentiating among the failures. liane
