Subject | Re: [firebird-support] Single trans per connection? |
---|---|
Author | Ann Harrison |
Post date | 2012-06-08T15:10:49Z |
On Fri, Jun 8, 2012 at 7:46 AM, Michael Ludwig <milu71@...> wrote:
interfaces. In the very old days, the normal programming language was not
SQL, but GDML - similar to a language Jim wrote at DEC called Datatrieve
and another language he wrote at CCA called Data Language. GDML allowed
you to qualify statements with transaction names and connections. At that
time, we implemented only a pure subset of SQL, so the SQL side of the
product, including the dynamic SQL interface, never allowed concurrent
transactions on a single connection.
What this history means is that the engine is inherently capable of
handling concurrent transactions in a connection but there is no way to use
them and the interface layers that surround the engine don't support the
capability. The requirement for multiple transactions per connection came
when a connection was very heavy-weight relative to a transaction. I'm not
convinced that's the case now.
Good luck,
Ann
[Non-text portions of this message have been removed]
> Kjell Rilbe schrieb am 08.06.2012 um 13:06 (+0200):Over their long lives, Firebird and InterBase have grown several layers of
> > Den 2012-06-08 12:04 skrev Helen Borrie s�h�r:
> > > the .net provider [�] the Firebird API.
> >
> > Well, it actually does seem like concurrent transactions are NOT
> > supported, as per version 2.6.5. That's what it actually says in the
> > exception I get when calling FbConnection.Begintransaction while my
> > first transaction is active.
>
> User Bill Karwin on StackOverflow.com:
>
> [�] most database brands don't support multiple concurrent
> transactions on a single connection (InterBase/Firebird is
> the only exception I know of).
>
interfaces. In the very old days, the normal programming language was not
SQL, but GDML - similar to a language Jim wrote at DEC called Datatrieve
and another language he wrote at CCA called Data Language. GDML allowed
you to qualify statements with transaction names and connections. At that
time, we implemented only a pure subset of SQL, so the SQL side of the
product, including the dynamic SQL interface, never allowed concurrent
transactions on a single connection.
What this history means is that the engine is inherently capable of
handling concurrent transactions in a connection but there is no way to use
them and the interface layers that surround the engine don't support the
capability. The requirement for multiple transactions per connection came
when a connection was very heavy-weight relative to a transaction. I'm not
convinced that's the case now.
Good luck,
Ann
[Non-text portions of this message have been removed]