Subject | Re: [Firebird-Java] InterClient vs. JCA-JDBC |
---|---|
Author | Helen Borrie |
Post date | 2002-05-23T10:10:22Z |
At 11:32 AM 23-05-02 +0200, Hans Georg wrote:
<g> If there is any final statement, it is that the better your designs
(structures, indexes, queries) the better your performance. Beyond that,
is more tweaking to tune things like memory cache, housekeeping, and so
forth. *Use* transactions, rather than fight them by using tricks like
autocommit to hide them; learn to avoid those long-running transactions
that slow...slow.......slow..........everything down, etc., etc.
works! What does he mean by "concurrency updates"? Concurrency is an
issue with all updates, even a single-user environment where an application
can work with multiple transactions.
There's nothing like "the last one wins". Optimistic row-level locking
applies. Two transactions can be looking at the same row but, until one
transaction actually posts an update request, both have an equal chance to
get the lock. It's the one which gets the lock first which wins,
regardless of which transaction started first.
You can use this trick to secure a "pessimistic lock" before your user even
posts a change. As soon as your user signals s/he wants to edit a row,
post a "dummy update request", e.g. update aTable set P_Key=P_Key where
P_Key=<constant>. Now, no other transaction will be able to post an update
request for that row until the first user either commits or rolls back
his/her transaction.
InterClient issue. I've never seen any InterClient documentation, per se,
though I suppose there must be some...
In the InterBase docs you have a frustrating search to find the useful
stuff on transactions. The *best* info is in EmbedSQL.pdf - in fact, the
documentation in this volume is in a class of its own. See also the
transaction-related stuff in the API Guide. If you have access to the
IBPhoenix Firebird manuals, there is a whole chapter on all the pertinent
aspects of transactions and transaction management. Also visit
http://www.cvalde.com for a couple of papers; and
http://www.ibobjects.com/TechInfo.html for some more.
Also read the archives of the ib-support list because this topic arises
frequently.
regards,
Helen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________
>Hi,There is no "final statement" - that's why there are so many discussions.
>
>I'm just evaluating access to Firebird 1.0 from Java-JDBC.
>
>I just have two Topics:
> 1. Performance
> 2. Concurrency/Transaction/Deadlock
>
>Is there any serious Information I can use?
>
>I found a lot of discussions about performance but non of them seems to
>have a final statement.
<g> If there is any final statement, it is that the better your designs
(structures, indexes, queries) the better your performance. Beyond that,
is more tweaking to tune things like memory cache, housekeeping, and so
forth. *Use* transactions, rather than fight them by using tricks like
autocommit to hide them; learn to avoid those long-running transactions
that slow...slow.......slow..........everything down, etc., etc.
>Anybody else told me that InterClient does not support concurrency. WhatInterclient is a client-side driver - it doesn't decide how the database
>that guy sais is that in situations of concurrency updates (in transactions)
>the last one wins!
works! What does he mean by "concurrency updates"? Concurrency is an
issue with all updates, even a single-user environment where an application
can work with multiple transactions.
There's nothing like "the last one wins". Optimistic row-level locking
applies. Two transactions can be looking at the same row but, until one
transaction actually posts an update request, both have an equal chance to
get the lock. It's the one which gets the lock first which wins,
regardless of which transaction started first.
You can use this trick to secure a "pessimistic lock" before your user even
posts a change. As soon as your user signals s/he wants to edit a row,
post a "dummy update request", e.g. update aTable set P_Key=P_Key where
P_Key=<constant>. Now, no other transaction will be able to post an update
request for that row until the first user either commits or rolls back
his/her transaction.
>Is there any information about this topic? Is there any otherYou need to read the literature about the *server*, since it is not an
>Information about InterClient and concurrency/transaction/deadlock?
InterClient issue. I've never seen any InterClient documentation, per se,
though I suppose there must be some...
In the InterBase docs you have a frustrating search to find the useful
stuff on transactions. The *best* info is in EmbedSQL.pdf - in fact, the
documentation in this volume is in a class of its own. See also the
transaction-related stuff in the API Guide. If you have access to the
IBPhoenix Firebird manuals, there is a whole chapter on all the pertinent
aspects of transactions and transaction management. Also visit
http://www.cvalde.com for a couple of papers; and
http://www.ibobjects.com/TechInfo.html for some more.
Also read the archives of the ib-support list because this topic arises
frequently.
regards,
Helen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________