PDA

View Full Version : Transactions over DataDictionary?



Mika Vainio
19-Feb-2005, 07:54 AM
Hello everybody

I'm trying to get started with transactions. Now I met the problem that the
begin_transaction command executes a lock (vdf help says "as a side-effect"
:)). This doesn't work in our application (don't ask me why). Until now I
could handle this by using the "request_save - way". Is there a possibility
to work-around the problem in a similar way here?

Best regards,
Mika Vainio

Peter Donovan
19-Feb-2005, 08:54 AM
Hi Mika,
When you say "it doesn't work" do you mean it hangs on a lock timeout or
other reason?
Also, what is your goal please?
Rgds,
Peter

Mika Vainio
19-Feb-2005, 09:33 AM
Peter,

I guess there is somewhere a dirty part in the db-structure. The problem is
that I actually don't have the time to fix this. With a lock/reread command
the programm goes to a deadlock. This does not happen, when I send
request_save to the dd...

The goal is the transaction standard: undo the changes in the db if
accounting fails.

Best regards,
Mika Vainio





"Peter Donovan" <sonatasoftwareus@yahoo.com> schrieb im Newsbeitrag
news:M2qRevoFFHA.1248@dacmail.dataaccess.com...
> Hi Mika,
> When you say "it doesn't work" do you mean it hangs on a lock timeout or
> other reason?
> Also, what is your goal please?
> Rgds,
> Peter
>

Sture Andersen
19-Feb-2005, 10:33 AM
Hi Mika,

It only takes a minute to fix. Here's what's happening:

You have alias tables in your system (more entries in filelist.cfg pointing
to the same physical table). When these are opened by your application this
makes VDF attempt to lock the same physical table more than once, which
ofcourse it can't do (it hangs your program).

In such a case you should have code like this:

open customer
open customer2
set_attribute DF_FILE_MODE of customer.file_number to DF_FILE_IS_MASTER
set_attribute DF_FILE_MODE of customer2.file_number to DF_FILE_IS_ALIAS

It doesn't matter which you set to master and which you set to alias. If you
have more than 2 filelist entries pointing to a particular table you simply
set the DF_FILE_MODE of each extra table to DF_FILE_IS_ALIAS.

It doesn't matter where you put the code as long as it executes on
application start up. But really it belongs in the DD source.

Setting these attributes will make your application able to handle a lock or
reread or begin_transaction without locking up.

The reason why your DD's are able to lock the database without hanging your
program is that they only lock the tables participating in the transaction.
And luckily for you this doesn't involve two alias tables (so far).

HTH

-Sture

Sture Andersen
19-Feb-2005, 10:35 AM
I should add that there is no other way to fix it.

-Sture

Mika Vainio
19-Feb-2005, 11:21 AM
hi sture

thanks for your explanations - so i guess i have to choose the stony way to
paradise... ;)

best regards,
mika vainio


"Sture Andersen" <sture.aps@mail.tele.dk> schrieb im Newsbeitrag
news:PomGUipFFHA.1248@dacmail.dataaccess.com...
>I should add that there is no other way to fix it.
>
> -Sture
>

Peter Donovan
19-Feb-2005, 11:26 AM
Hi Sture,
What about my TranLock.Pkg which duplicates what a DDO tree does?

Then you can use saverecord inside a transaction block without hanging.

??
Peter

Sture Andersen
19-Feb-2005, 12:14 PM
Hello Peter,

It looks like it could be used as an alternative route to paradise.

-Sture

Peter Donovan
19-Feb-2005, 12:16 PM
Yes,
It optimizes the reread so that only the files marked default get locked,
and therefore it fixes the alias situation.
It's tried and true: been around awhile: I just touched it up a little and
the original composer (probably Ben W) hasn't claimed it yet.
It's very dependable.
(wish I could be as poetic as you with the wording though)
Peter
www.sonatasoftware.us

Sture Andersen
19-Feb-2005, 12:34 PM
> (wish I could be as poetic as you with the wording though)

Mika taught me ;-)