hello to everyone, i would like ta make an example about my problem . . let us say that there is 3 houses and those three houses have been installed with the same program that i have created . . but those 3 houses only connect to a single server and same database . . . now the problem is what happend when those three houses suddenly do a transaction and i have locks on my query inside my program . . . some have an exclusive locks on it . . . now the problem also is that i have a transaction sequence which it is only updated every transaction made by those 3 houses . . . what if those 3 houses suddenly made a transaction simultaneosly . . . ? what would be the behavior of the program on simultaneosly updating only one field that has exclusive lock on it . . ? tanx ........
Transactions in ABL are scoped to a block. When the transaction block completes, all the changes are committed to the database. If the transaction block does not complete, all the changes made during the transaction will be rolled back.
To change a record in the database, you must have an exclusive-lock on the record. The default lock type in ABL is share-lock (danger here - generally speaking you should never use the default locking type, always specifying no-lock if you're not going to change the record and exclusive-lock if you are going to change the record - there are a couple of exceptions to this rule).
An exclusively-locked record will stay exclusively-locked until the end of the transaction. Only one user can have an exclusive-lock on any given record at a time. If you are using a pessimistic locking approach, you will never end up in situations where one transaction clobbers another. That said, pessimistic locking tends to be a thing of the past and in most cases optimistic locking will be used. For optimistic locking, you need to make sure that nobody else changed the record while you weren't looking.
It's important to realise that the transactions themselves will never destroy each other's data, but with optimistic locking, if it's not implemented correctly, data can (and will) go missing.
More information on transactions, record locking, record scopes, etc, can be found in the documentation: http://www.psdn.com/library/entry.jspa?externalID=4818
thank you very much . . it was very helpful to me . . actually we are a team of developer that develops a banking system and we are using both open edge and web base which is the speedscript but we are all fresh graduate of an IT school . . . . and the system is a web base application . . . i am just wondering what if the teller of the bank uses the tellering module at the same time . . . . just trying to update you . . . can you give me some tips on your experience on record locking and which probably the right way to use optimistic or pessimistic locking . . . . tanx a lot . . .
The key principle here is to have no locks or active transactions during user interaction and then to have a very tightly scoped transaction when all the data is ready to be committed. This does mean that your commit logic has to take into account some error handling, e.g., if the data changed from the conditions as they were displayed on the screen. And, it could include logic that will retry if the needed records are locked. But, by tightly scoping the transaction, the entire duration of the transaction will be very short and the likelihood of having multiple stations updating the same record extremely small. The one caution on the later point comes from the use of control records that need to be accessed by every transaction, e.g., to get the next transaction audit trail number. You should avoid that design in favor of sequences whenever possible.