Thanks a lot for the quick response
Manjula Piyumal, September 08, 2016 - 7:07 am UTC
Thanks a lot for your quick response and suggestions. I'm thinking whether this will suit my requirement since I'm doing this data moving task in three pairs of tables and I want them to proceed with a single transaction. So if I have to go with your suggestion, I have to lock all three tables before proceeding which may lead to a complex logic :-(
Could you please help me to understand whether there is a way to return without keeping any locks at the server side. The problem in even with your suggestion what will happen if I cannot complete the task after acquiring the exclusive lock on the table? Let's say that I have a lot of rows to move and I cannot complete the data movement task before readtimeout value(may be due to other external facts). As I have observed, the behaviour will be my client will be returned with a socket read time out exception and my delete statement will the there forever since I couldn't either commit or rollback my transaction because my connection is already closed at the driver level in socket read timeouts. I'm not sure whether I have missed something here, so your help and suggestions are really appreciated. I want to guaranty that I won't keep any stale locks if I couldn't complete my transaction due to network level failures or any failures that I will hit at the client side and database server will rollback my locks if my client is not connected any longer
Thanks,
Manjula
September 08, 2016 - 12:50 pm UTC
You are *always* holding locks on the server side. The moment you update 1 row you have taken out locks. And if your client simply "forgets" about the database when it times out, then no matter what you do, you are doing to have locks left hanging around.
You could look at resource manager or profiles to try clean up the mess after a certain time...but basically, if your client doesnt behave well with the database, then you're going to have troubles.