|
| [WD20] Transactions and isolation... |
| Iniciado por guest, 16,feb. 2016 17:54 - 6 respuestas |
| |
| | | |
|
| |
| Publicado el 16,febrero 2016 - 17:54 |
Hi,
Now I'm converting an app over to Client/Server mode, there's a whole new world of Transactions and "isolation" modes opening up in front of me - allowing me to be in control of commit points :xcool: ...something I've taken for granted in Oracle.
Q: Has anyone seen the need to use HTransactionIsolation yet? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 17,febrero 2016 - 12:57 |
Hi Darren,
I use it to set the mode to Read-committed so that other users only see finalized transactions:
lbTrsOk = HTransactionIsolation(pgctMyConnection,hReadCommitted)
BTW, it is only usable at HFSQL Client/Server, not in Classic mode which is always read-uncommitted. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 17,febrero 2016 - 14:50 |
Hi Stefan,
Thanks for responding...
Yes, I got that; only for C/S :spos:
After reading the Help, I think I'm going to use HTransactionStart with it's Read-Uncommitted default, but it's good to know about the alternative isolation modes. I just need to control the processing in the eventuality of an error during a database intensive bit of processing, so being able to carry out a ROLLBACK is very important to keep the consistency/integrity of the data.
Thanks again... |
| |
| |
| | | |
|
| | |
| |
| Publicado el 18,febrero 2016 - 13:57 |
Darren
I am sure you know what you are doing but for others reading with less experience.
I have never found that 'one size fits all'.
Unlike the mainstream DB's HF makes all records written/modified available when using the default hReadUncommitted.
Great for testing/debugging but if you are in a multi user environment and users or queries access the data you are writing/modifying you can get unwanted consequences.
Sure we all follow the rules to keep transaction periods as short as possible but this is not always a option.
I have cases were I post to an accounts system via third party interface software and need to wait for a response before committing or rolling back - in this instance I use hReadCommitted.
Not sure what you mean by 'database intensive' but if it means that the transaction will be active for more than a few seconds I would recommend this option. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 18,febrero 2016 - 15:24 |
Hi Derek,
Nope... I know what I'd like to happen... what I meant to say was that I'm going to "start" with Read-Uncommitted 
By database intensive, I mean several inter-related files/tables being read and modified one after another, but not as intensive as your example, i.e. it's not a batch-type process. However, it will (eventually), be several PCs (clients) hitting these product, stock, accounting tables.
Are you saying that record locking within transactions doesn't work in some way or is unpredictable or something else? Have you used HMode or HLockFile? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 18,febrero 2016 - 18:19 |
Darren
My understanding is that actual records taking part in a transaction are not locked automatically.
I have never read anything to indicate that they are.
I have not used hMode and would never want a complete file locked.
I guess it depends on what your application is designed for.
In my app all records that may be involved in posting to the accounts have a batch number.
As soon as these are accessed a record is written to the nicely named 'BatchLock' file which means only one user can ever post a given batch.
All other (single) records opened for editing are locked, usually as ReadWrite, in the normal way.
This regardless of whether they may be involved in a transaction or not.
The reason I use hReadCommitted is that there are many other windows where the records in the Transaction can be seen and/or updated plus many reports based on the files in question.
Having a user being able to see or report on records that are not yet part (uncommitted) of the data set serves no purpose and could well lead to any number of issues up the line.
As said I have not fully investigated the 'lock' status of a record that is part of a transaction.
If I get a mo at the weekend I may well have a play to see what the score is on that. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 18,febrero 2016 - 18:34 |
Derek,
Thanks... I too haven't seen anything that mentions locking within transactions. Hmmm, HRead... statements can lock, but precisely the same statements within a Transaction ignore locking? ...that's interesting.
In that case, I might "start" with read-committed and see where my testing leads me.
I'll update this thread with my findings... |
| |
| |
| | | |
|
| | | | |
| | |
|