One option is to use "SELECT FOR UPDATE WITH LOCK" ...if a second thread
attempts to obtain a LOCK, it will throw an exception. This is ideal if you
are only editing one row at a time. You have to think about "dead clients"
though. If a client loses connection, the row is locked till the server
determines that the client is indeed dead. The default is 2 hours (i think)
but you can manipulate it. I have a windows forms application using
ADO.NETthat has worked well with this mechanism. I can send you more
details if you
need.
On 8/1/07, Kevin Donn <[EMAIL PROTECTED]> wrote:
>
> I could use a bit of help deciding how best to use transactions in a
> particular case. I've used transactions quite a bit before, but my goal has
> always been simply to be able to commit or rollback groups of changes. In
> my current case, I've got to worry about concurrent access.
>
> I expect my asp.net application to occasionally get multiple requests more
> or less simultaneously that will cause me to need to edit the same row in a
> table. The process that edits the row needs to fetch data, load it into a
> DataTable, examine it, make changes if necessary, and then update the
> database with the changes to the row. If another request comes in, I don't
> want it to even be able to read the data until the first thread has
> completely finished. I would like the second thread to simply wait until
> the first thread finishes before being able to do the read.
>
> Which overload of FbConnection.BeginTransaction would be most appropriate,
> and which options should I use?
>
> I've read through the old Interbase documentation for transactions (I
> failed to find anything Firebird-specific) and it seems there is no level of
> transaction control that will work the way I've described since they'll all
> allow the two threads to read the row, which now that I think about it, is
> probably always the smartest thing to do. My problem is that I want to
> essentially serialize changes to individual rows.
>
> Perhaps the correct approach is to use the Concurrency model. Then both
> threads would read the row. One would succeed in making changes and sending
> the update, but the other would then fail. Presumably, the one that fails
> would throw an exception of some kind, and I could just retry the entire
> fetch/examine/change/update cycle until is succeeds. Is that the correct
> approach?
>
> Thanks much,
> Kevin Donn
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Firebird-net-provider mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Firebird-net-provider mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
