firebird-net-provider

[Firebird-net-provider] Normal or retained commit/rollback of transactions

[Jojakim S. <JS...@de...>]

Hello!
I studied code of FbTransaction and found that Rollback() and Commit() use
the *_retaining version for committing / rolling back transactions. After a
retained commit/rollback automatically a "new" transaction is started,
indicated by a transaction state of TxnState.TRANSACTION_STARTED. Now, a
call to FbConnection.BeginTransaction() failes.

But this is, in my opinion, not what the normal developer expect (compared
to other RDBMS). Also, the retained commit/rollback preserves the snapshot
of the former transaction, which again may not result in a behavior
comparable to other RDBMS.

I propose to introduce a property to the connection and/or transaction
objects to set the commit/rollback mode to retaining or normal. In normal
mode, the Commit()/Rollback() methods must call the standard
GDS-transaction-functions and set the TxnState to TxnState.NOTRANSACTION.
For retaining mode, the behavior is acceptable like it is now.

Just my thoughts on that topic, any comments welcome.

-- Joja

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:
Hello!

> I studied code of FbTransaction and found that Rollback() and Commit() use
> the *_retaining version for committing / rolling back transactions. 
> After a
> retained commit/rollback automatically a "new" transaction is started,
> indicated by a transaction state of TxnState.TRANSACTION_STARTED. Now, a
> call to FbConnection.BeginTransaction() failes.


I make this after see documentation of SqlClient, OleDb, And Odbc .Net 
providers by Microsoft that doesn´t allow parallel transactions, i want 
to make this the most conmpaitble as possible with other .net providers.

> But this is, in my opinion, not what the normal developer expect (compared
> to other RDBMS). Also, the retained commit/rollback preserves the snapshot
> of the former transaction, which again may not result in a behavior
> comparable to other RDBMS.
>
> I propose to introduce a property to the connection and/or transaction
> objects to set the commit/rollback mode to retaining or normal. In normal
> mode, the Commit()/Rollback() methods must call the standard
> GDS-transaction-functions and set the TxnState to TxnState.NOTRANSACTION.
> For retaining mode, the behavior is acceptable like it is now.


This can be a good idea i can see how other providers manage commiting 
and rollbacking transactions.




Best regards
Carlos Guzmán Álvarez
Vigo-Spain

>
> Just my thoughts on that topic, any comments welcome.
>
> -- Joja
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:

 > I studied code of FbTransaction and found that Rollback() and 
Commit() use
 > the *_retaining version for committing / rolling back transactions. 
After a
 > retained commit/rollback automatically a "new" transaction is started,
 > indicated by a transaction state of TxnState.TRANSACTION_STARTED. Now, a
 > call to FbConnection.BeginTransaction() failes.



I make this after see documentation of SqlClient, OleDb, And Odbc .Net 
providers by Microsoft that doesn´t allow parallel transactions, i want 
to make this the most conmpaitble as possible with other .net providers.

 > But this is, in my opinion, not what the normal developer expect 
(compared
 > to other RDBMS). Also, the retained commit/rollback preserves the 
snapshot
 > of the former transaction, which again may not result in a behavior
 > comparable to other RDBMS.
 >
 > I propose to introduce a property to the connection and/or transaction
 > objects to set the commit/rollback mode to retaining or normal. In normal
 > mode, the Commit()/Rollback() methods must call the standard
 > GDS-transaction-functions and set the TxnState to TxnState.NOTRANSACTION.
 > For retaining mode, the behavior is acceptable like it is now.



This can be a good idea i can see how other providers manage commiting 
and rollbacking transactions.




Best regards
Carlos Guzmán Álvarez
Vigo-Spain

 >
 > Just my thoughts on that topic, any comments welcome.
 >
 > -- Joja
 >
 >
 >
 > -------------------------------------------------------
 > This sf.net email is sponsored by:ThinkGeek
 > Welcome to geek heaven.
 > http://thinkgeek.com/sf
 > _______________________________________________
 > Firebird-net-provider mailing list
 > Fir...@li...
 > https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
 >

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Jojakim Stahl wrote:

 > Hello!
 >
 > A got the new CVS version and had problems to call
 > FbConnection.BeginTransaction() a second time after disposing the
 > FbTransaction-object returned by the first call.
 > I studied code and found that FbTransaction.Dispose() doesn't reset the
 > active transaction object of the connection. Due to the simple test for
 > activeTxn != null when calling FbConnection.BeginTransaction() the second
 > call throws.



I make this after see documentation of SqlClient, OleDb, And Odbc .Net 
providers by Microsoft that doesn´t allow parallel transactions, i want 
to make this the most conmpaitble as possible with other .net providers.

 > I added an internal property to FbTransaction to query the transactions
 > state and extended the test in FbConnection.BeginTransaction() to 
check the
 > state.



Thanks very much ;), i´m seeing now how other providers manage this 
issue, can you send the patches with diff -u please.



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:

 >>Thanks very much ;), i´m seeing now how other providers manage this
 >>issue, can you send the patches with diff -u please.

I´m testing this and microsoft providers throw exception if you make 
anything like this:

	...
	myTrans.Rollback();	<-- this make connection to be capable 							of 
begin a new transaction
	myTrans.Commit();	<-- This throw InvalidOperationException
	...

or
	...
	myTrans.Commit();	<-- this make connection to be capable 							of 
begin a new transaction
	myTrans.Rollback();	<-- This throw InvalidOperationException
	...



I can made the changes needed for work if there are no opinions against 
it :)




Best regards
Carlos Guzmán Álvarez
Vigo-Spain

AW: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[Jojakim S. <JS...@de...>]

I propose the standard behavior should be like the MS providers.
But what do you think about the normal/retaining problem?

I looked at the documentation of the SqlTransaction class for MSSQLServer.
They implemented savepoints within transactions by introducing a
non-IDbTransaction method Save(string savepoint) and overloaded Commit and
Rollback with version that accept these savepoints. However standard
behavior is BeginTransaction(), Commit() or Rollback().

What about building a similar solution: BeginTransaction(), Commit(bool
retaining) or Rollback(bool retaining). Standard Commit() / Rollback() call
these methods with retaining=false. The only thing, I'm not sure about is,
whether it should be necessary to call BeginTransaction() after a
Commit/Rollback(retaining=true). I tend to prefer not to call
BeginTransaction() again.

I included the changes from yesterday as diff -u now.

Greetings, Joja

> -----Ursprüngliche Nachricht-----
> Von: fir...@li...
> [mailto:fir...@li...]Im Auftrag von
> Carlos Guzmán Álvarez
> Gesendet am: Donnerstag, 21. November 2002 18:35
> An: Firebird .Net Provider; Jojakim Stahl
> Betreff: Re: [Firebird-net-provider] Normal or retained commit/rollback
> of transactions
>
> Hello:
>
>  >>Thanks very much ;), i´m seeing now how other providers manage this
>  >>issue, can you send the patches with diff -u please.
>
> I´m testing this and microsoft providers throw exception if you make
> anything like this:
>
> 	...
> 	myTrans.Rollback();	<-- this make connection to be
> capable 							of
> begin a new transaction
> 	myTrans.Commit();	<-- This throw InvalidOperationException
> 	...
>
> or
> 	...
> 	myTrans.Commit();	<-- this make connection to be
> capable 							of
> begin a new transaction
> 	myTrans.Rollback();	<-- This throw InvalidOperationException
> 	...
>
>
>
> I can made the changes needed for work if there are no opinions against
> it :)
>
>
>
>
> Best regards
> Carlos Guzmán Álvarez
> Vigo-Spain
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Firebird-net-provider mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>

Re: AW: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:

> I propose the standard behavior should be like the MS providers.
> But what do you think about the normal/retaining problem?
>
> I looked at the documentation of the SqlTransaction class for MSSQLServer.
> They implemented savepoints within transactions by introducing a
> non-IDbTransaction method Save(string savepoint) and overloaded Commit and
> Rollback with version that accept these savepoints. However standard
> behavior is BeginTransaction(), Commit() or Rollback().


As i know savepoints are implemented on FB 1.5, can be a good idea to 
implement a Save(string savepointName) on FbTransaction ??

> What about building a similar solution: BeginTransaction(), Commit(bool
> retaining) or Rollback(bool retaining). Standard Commit() / Rollback() 
> call
> these methods with retaining=false. The only thing, I'm not sure about is,
> whether it should be necessary to call BeginTransaction() after a
> Commit/Rollback(retaining=true). I tend to prefer not to call
> BeginTransaction() again.


I have no problem in add these two methods as overloaded methods for 
Commit and Rollback but possible can be better to implement savepoints.

Comments are welcome on this issue :)

> I included the changes from yesterday as diff -u now.


Thanks very much this makes more easy to me to apply patches :) .



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[Jojakim S. <JS...@de...>]

> > What about building a similar solution: BeginTransaction(), Commit(bool
> > retaining) or Rollback(bool retaining). Standard Commit() / Rollback()
> > call
> > these methods with retaining=false. The only thing, I'm not
> sure about is,
> > whether it should be necessary to call BeginTransaction() after a
> > Commit/Rollback(retaining=true). I tend to prefer not to call
> > BeginTransaction() again.
>
>
> I have no problem in add these two methods as overloaded methods for
> Commit and Rollback but possible can be better to implement savepoints.

But as far as I know, savepoint and retaining transactions are not the same.
If you commit retaining, you have no possibility to rollback what you have
committed, only the transaction environment (=the snapshot of row versions)
remains within the new transaction.

A savepoint is a point within an overall transaction (I don't know the exact
implementation in firebird 1.5, so I speak with the MSSQLServer knowledge),
you can
BeginTransaction("Point0");
DBOps...
Save("Point1");
DBOps...
Save("Point2");
DBOps...
Rollback("Point1");   // Cancels all DBOps made since Save("Point1")
DBOps...
Save("OtherThings");
Rollback("Point0");   // Cancels complete transaction

So if firebird 1.5 has savepoints, perhaps we need both methods.
To propose some good method names and signatures I have to look at firebird
1.5 docu/source to inform myself about the savepoints implemented there.

-- Joja

Re: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:

> But as far as I know, savepoint and retaining transactions are not the 
> same.
> If you commit retaining, you have no possibility to rollback what you have
> committed, only the transaction environment (=the snapshot of row 
> versions)
> remains within the new transaction.
>
> A savepoint is a point within an overall transaction (I don't know the 
> exact
> implementation in firebird 1.5, so I speak with the MSSQLServer 
> knowledge),
> you can
> BeginTransaction("Point0");
> DBOps...
> Save("Point1");
> DBOps...
> Save("Point2");
> DBOps...
> Rollback("Point1");   // Cancels all DBOps made since Save("Point1")
> DBOps...
> Save("OtherThings");
> Rollback("Point0");   // Cancels complete transaction
>
> So if firebird 1.5 has savepoints, perhaps we need both methods.
> To propose some good method names and signatures I have to look at 
> firebird
> 1.5 docu/source to inform myself about the savepoints implemented there.
>


Well, i´m going to update my changes of thisto the CVS,  i think this 
can be a good starting point for make a definitive implementation for 
transaction management, and i´m going to ask on firebird-devel how 
savepoints work on firebird 1.5 compared with yopur Sql Server example.

Thanks for your feedback on this issue :)



Best regards
Carlos Guzmán Álvarez
Vigo-Spain

AW: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[Jojakim S. <JS...@de...>]

> Well, i´m going to update my changes of thisto the CVS.....

I updated my version to the current CVS.
When FbTransaction.Dipose() is called and the tran is rolledback, isUpdated
was not set to true, therefore FbConnection().BeginTransaction() failed.

I found this using the construct
using (FbTransaction transaction = connection.BeginTransaction())
{
	// do something which failes and therefore doesn't execute Commit()
	// but implicitly calls transaction.Dispose()
	transaction.Commit();
}

-- Joja

Re: AW: [Firebird-net-provider] Normal or retained commit/rollback of transactions

[<car...@te...>]

Hello:

> >Well, i´m going to update my changes of thisto the CVS.....
>
>
> I updated my version to the current CVS.
> When FbTransaction.Dipose() is called and the tran is rolledback, 
> isUpdated
> was not set to true, therefore FbConnection().BeginTransaction() failed.
>
> I found this using the construct
> using (FbTransaction transaction = connection.BeginTransaction())
> {
> 	// do something which failes and therefore doesn't execute Commit()
> 	// but implicitly calls transaction.Dispose()
> 	transaction.Commit();
> }



Thanks very much for this, i have it updated only with one change.
Instead of :

	FbIscConnection.gds.isc_rollback_transaction(tr);

use:

	InternalRollback(false);


Best regards
Carlos Guzmán Álvarez
Vigo-Spain