| 6/22/2006 9:36:56 AM |
I have a client-server application that uses the ormapper. There are multiple users, but for the most part each user is working on separate data, although the data is in the same tables. The database server is across a VPN, so there is significant latency with all database calls. Some of the operations require inserting or updating multiple records in a single transaction. So if a transaction is taking 5 to 10 seconds to complete, the tables are basically locked during that time, correct? Users are getting frequent deadlock errors. Is the proper way to handle this by using transactionlevel.readuncommited? That seems a little dangerous. Can you reccomend any other strategy?
Thanks,
David Martines |
| 6/22/2006 9:40:53 AM |
Hi David:
Wow -- that's some significant latency. The next version will allow you to specify locking hints, assuming you're using MS Sql, which will mean that you can force all of your reads to use (nolock) -- that may be sufficient, but it would certainly help if nothing else. In the meantime, you may have to specify a different transaction level as you've noted -- I can't really claim to have the experience with this situation to offer a sure recommendation though.
Thanks, Paul Wilson
|
| 6/22/2006 3:03:47 PM |
Thanks - the nolock hint sounds like it will do the trick. Since some of the operations must insert or update many objects (sometimes over 100), in one case I have resorted to making a very chunky call to the database by using a stored proc. The proc accepts an xml string containing the list of objects to persist and takes care of the inserting within it's own transaction. This is definately a last-resort since it pretty much defeats the purpose of using an ormapper. I plan to re-architect the app to use remoting at some point and run the ormapping assembly right on the db server. This will let the mapper handle the persistence but in much quicker transactions.
David
|