Subject | Re: Very fast read only transactions |
---|---|
Author | jeff_j_dunlap |
Post date | 2009-01-22T03:49:10Z |
--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:
containing an instance of an open database and a boolean 'is_busy' flag.
Each structure can contain it's own verify_connection() & reconnect()
routines to ensure that something didn't happen to the connection like
FB server shutdown, or some other connection failure.
would create new db instances and connect and disconnect for each
transaction. Doing so spikes the processor, uses more memory, and
causes disk trashing (because data buffering is lost). Running my own
recent tests, I was able to reproduce this and am fully convinced that
connect() is not a cheap operation--too expensive to use in a web
application.
Some FB users on linux have told me that buffering is maintained after
disconnect() but I'm on a windows server and buffering is lost after
disconnect().
Now, I am seriously impressed with Firebird's performance on db
connections that remain open and really wish I would have known this
before!
As for a read-only transaction, you mentioned commit and I'm a bit
confused. In my tests, I have not been committing read-only
transactions since I thought that commit was for write operations. Is
commit required for read-only transactions? If so, why?
Anyway, I sincerely appreciate all of the pointers you provided and am
eager to receive any other suggestions or criticism since it will only
help me and FB users I'm sure.
Thanks again and best regards,
Jeff
>My plans are to build a small vector of structures, each structure
> Are you intending on sharing the single connection/transaction
> instance between your web users? If so, you are going to
> encounter some thread-safety issues or some serialisation
> bottlenecks. In simple terms, what happens to user 2 if when
> they connect to your web application, user 1 is already using
> the connection?
containing an instance of an open database and a boolean 'is_busy' flag.
Each structure can contain it's own verify_connection() & reconnect()
routines to ensure that something didn't happen to the connection like
FB server shutdown, or some other connection failure.
> Anyway, back to Firebird; I would imagine the overhead ofIn my first FB app, I was unhappy with the delay caused by the way I
> starting and committing a transaction is significantly lower
> than the overhead of waiting for an available connection from
> the pool of 1.
> You should do some profiling to see the time taken to start
> and commit a read only transaction to see whether you are
> fighting a problem that only exists in your mind.
would create new db instances and connect and disconnect for each
transaction. Doing so spikes the processor, uses more memory, and
causes disk trashing (because data buffering is lost). Running my own
recent tests, I was able to reproduce this and am fully convinced that
connect() is not a cheap operation--too expensive to use in a web
application.
Some FB users on linux have told me that buffering is maintained after
disconnect() but I'm on a windows server and buffering is lost after
disconnect().
Now, I am seriously impressed with Firebird's performance on db
connections that remain open and really wish I would have known this
before!
As for a read-only transaction, you mentioned commit and I'm a bit
confused. In my tests, I have not been committing read-only
transactions since I thought that commit was for write operations. Is
commit required for read-only transactions? If so, why?
Anyway, I sincerely appreciate all of the pointers you provided and am
eager to receive any other suggestions or criticism since it will only
help me and FB users I'm sure.
Thanks again and best regards,
Jeff