Raul


My problem is that the manual makes no mention of it being specific to a session, and I know transactions apply across sessions.

Roy Lambert

That is the same reason why I asked. The manual is not clear to me.

Roy Lambert wrote:

Raul

My problem is that the manual makes no mention of it being specific to a session, and I know transactions apply across sessions.

Roy Lambert

On 4/29/2019 7:06 AM, Mike wrote:
> That is the same reason why I asked. The manual is not clear to me.
> Roy Lambert wrote:
>
> My problem is that the manual makes no mention of it being specific to a session, and I know transactions apply across sessions.

Mike and Roy,

I think this is something we can ask Tim to clarify.

However logically if it were working any other way it would not be
usable since you would have no way of "knowing" whether it's "your"
transaction or not before making changes.

For remote sessions you CAN query ServerSessionLocks for transaction
locks (unfortunately you need admin access) to see what else is happening.

Raul

Thank you Raul for clarifying things.
Anyway, I can't see any practical use on testing if some other session has an active transaction on a database.
A function that returns if some other session has an active transaction wouldn't be reliable because its return value is outdated at the very moment it returns.

--
Fernando Dias
[Team Elevate]

Raul

>However logically if it were working any other way it would not be
>usable since you would have no way of "knowing" whether it's "your"
>transaction or not before making changes.

Hmmm, being the awkward sort - how far can you get with a transaction before you're locked waiting for some other transaction to complete?

>For remote sessions you CAN query ServerSessionLocks for transaction
>locks (unfortunately you need admin access) to see what else is happening.

I wondered if there was something like that but hadn't got round to looking yet. Thanks for the info.

Roy

Fernando

>Anyway, I can't see any practical use on testing if some other session has an active transaction on a database.

I can make some halfway decent use case for it. A bit like calling Edit on a row, but for a database.

>A function that returns if some other session has an active transaction wouldn't be reliable because its return value is outdated at the very moment it returns.

I don't understand your point here. I can't seem to get my head round what you think is happening. Why is it outdated when it returns?

Roy

On 4/29/2019 1:26 PM, Roy Lambert wrote:
> Hmmm, being the awkward sort - how far can you get with a transaction before you're locked waiting for some other transaction to complete?

You cannot even start one if there is another transaction in progress -
i.e. "StartTransaction" call blocks and/or times our with an exception
if it cannot start it after timeout.

One thing to keep in mind is that transactions can be restricted -
meaning you can specify which tables to apply it to (instead of whole DB).

In that case you can have multiple transactions in progress at the same
time - as long as they don't overlap for tables affected.

i.e. Roy can be adding users and contacts with his transaction on User
and Contacts table while Raul is adding POs and lineitems for PO and
Lineitem tables.

Raul

On 4/29/2019 1:01 PM, Fernando Dias wrote:
> Anyway, I can't see any practical use on testing if some other session
> has an active transaction on a database.
> A function that returns if some other session has an active transaction
> wouldn't be reliable because its return value is outdated at the very
> moment it returns.

Agreed - my view is same : use StartTransaction with timeout and if it
succeeds you're good to go and if not you know something else (likely a
transaction but could be any other lock) is preventing it.

Raul

Roy,

Because one fraction of a second after the function tests for an active transaction and even before the return happens, any other session might start, commit or rollback a transaction and the result is already wrong when it is returned.

--
Fernando Dias
[Team Elevate]

Exactly.
It's the same with row locks.
The only reliable way to test if a row is locked by another session is to try to lock it, i.e. Edit it.
In conclusion, InTransaction works for Databases like (TDataset.State in [dsEditModes]) for Datasets.
--
Fernando Dias
[Team Elevate]