Subject | RE: [IBO] Newbie transaction questions |
---|---|
Author | Alan McDonald |
Post date | 2002-12-10T07:25:48Z |
Joe,
You should not be "querying" for the key. You should be "getting" the next
generator value. IBO can do that by setting the generator links, or you can
get it via a separate query or a stored procedure. Generators are fired
outside the context of a transaction so no two evem simultaneous users can
get the same key. There requests are simply queued and get the next value.
Armed with a (guaranteed) unique key, each user can then proceed under
whatever transaction mechanism they choose to commit their work.
Alan
-----Original Message-----
From: Joe Martinez [mailto:joe@...]
Sent: Tuesday, 10 December 2002 5:50 PM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] Newbie transaction questions
execution? Is that a bad thing in my situation?
Is the purpose of transactions basically to control when commits are done,
or is there more to it than that?
I'm a little confused about how commits and transactions interact with key
violations. In my situation, the client queries the database to find out
what the last key used was. It then increases that number by one and
inserts a record with that key. Let's say two users are doing this
simultaneously. They may both query at the same time and try to store
records with the same key. Now, if Client A inserts first, but doesn't
commit yet, then Client B inserts, will Client B get an immediate key
violation? If not, then does the first one to commit succeed, and the
other get a key violation? Or, does Client A get preference for having
inserted first? I guess I'm basically asking two questions: 1) Does the
insert reserve the key, or does the commit reserve it? 2) Does in insert
trigger a key violation, or does the commit trigger it?
Here's my concern: After inserting the master record, the app needs to
insert several detail records, including the master's key for later
reference. If there's going to be a key conflict on the master records, I
want to know that BEFORE I start inserting detail records. Otherwise, the
detail records could get linked to the wrong master record, causing a nasty
mess to clean up if the master record insert fails. Does that mean that I
should commit the master record before inserting the detail records? If
so, wouldn't that be a reason to make it two transactions instead of one?
-Joe
___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
You should not be "querying" for the key. You should be "getting" the next
generator value. IBO can do that by setting the generator links, or you can
get it via a separate query or a stored procedure. Generators are fired
outside the context of a transaction so no two evem simultaneous users can
get the same key. There requests are simply queued and get the next value.
Armed with a (guaranteed) unique key, each user can then proceed under
whatever transaction mechanism they choose to commit their work.
Alan
-----Original Message-----
From: Joe Martinez [mailto:joe@...]
Sent: Tuesday, 10 December 2002 5:50 PM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] Newbie transaction questions
>You should have the insert of a master and its detail records within thedefault
>context of a single unit of work. You can use the default transaction or an
>explicit one that you use for this. Keep in mind a TIBODatabase will
>to AutoCommit as true and a TIB_Transaction will default to AutoCommit asDoes AutoCommit mean that each insert is committed immediately after
>false.
execution? Is that a bad thing in my situation?
Is the purpose of transactions basically to control when commits are done,
or is there more to it than that?
I'm a little confused about how commits and transactions interact with key
violations. In my situation, the client queries the database to find out
what the last key used was. It then increases that number by one and
inserts a record with that key. Let's say two users are doing this
simultaneously. They may both query at the same time and try to store
records with the same key. Now, if Client A inserts first, but doesn't
commit yet, then Client B inserts, will Client B get an immediate key
violation? If not, then does the first one to commit succeed, and the
other get a key violation? Or, does Client A get preference for having
inserted first? I guess I'm basically asking two questions: 1) Does the
insert reserve the key, or does the commit reserve it? 2) Does in insert
trigger a key violation, or does the commit trigger it?
Here's my concern: After inserting the master record, the app needs to
insert several detail records, including the master's key for later
reference. If there's going to be a key conflict on the master records, I
want to know that BEFORE I start inserting detail records. Otherwise, the
detail records could get linked to the wrong master record, causing a nasty
mess to clean up if the master record insert fails. Does that mean that I
should commit the master record before inserting the detail records? If
so, wouldn't that be a reason to make it two transactions instead of one?
-Joe
___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/