Temp Table Query

[SSuhaib]

Hi,

If temp tables are used to pass as parameters in an n-tier application, then how is concurrency maintained. I mean, if user A modifies records of a table and those records are passed as temp tables and at the same time another user B modifies same record at the same time then which one is updated in the database. In client server we have concepts of locks, how are locks maintained in n-tier.

Thanks in advance.

 

[RealHeavyDude]

The concept of optimistic locking ( which should by utilized by any modern business application in order to avoid locking contention ) does not depend on the fact whether you use client/server or n-tier architecture. It's just that in an n-tier architecture it's enforced since you don't have any database access on the client, therefore records in the database can only be locked for the time the server side logic to store the changes needs to complete. It's up to you to implement something in your business logic that checks whether the record has been changed in the meantime by another user and reject the changes or not.

Theses are discussion I used to have 10 or more years ago. So to speak, the concept of optimistic locking in a client/server environment or an n-tier environment does not hold water, because otherwise your business logic would need to reject each update to the database as soon as the record has been changed by some else. Out of experience I can tell you that in most scenarios a "the last one wins" approach will do. It's only rare scenarios where this conflicts with business rules and/or regulatory compliance. In such cases you need to set up the rules and implement them.


Regards, RealHeavyDude.

 

[MaximMonin]

N-tier architecture relies on using state-free appserver mode.
It is impossible to keep lock if client disconnects from DB. So you have to implement business logic when record updated.

The only way to keep record locking is create persistent object on server side. It consumes 1 thread of appserver. And you have to work with this persistent object in single thread mode (just like client-server).

 

[tamhas]

Actually, if you are happy passing TTs back and forth the TT in sufficiently modern versions of ABL has before-image and state tracking which provides you will all the information you need to do optimistic locking. If you want, when the record is changed, you can even do buffer compares and attempt a field-level merge, if you want, and choose whether or not to send a merged record back to the client for validation.

 

[GregTomkins]

I'm with RHD on this one. 9 times out of 10, nobody cares. Say you are updating an address or a part description or something like that. Most of the time, you just want to change it to whatever you think it should be. If someone else slipped in a conflicting change since you started looking at it, you don't care. What's the point of building a bunch of complexity to tell people there was a conflict when it will just confuse them?

Of course, if you're talking about stuff like $$ balances in bank accounts, well, that's different, and you should generally build things around the notion of "add X dollars to this balance" rather than "I think the balance should be X"... which solves the problem simply and robustly.