OGRLayer::StartTransaction()/CommitTransaction()/RollbackTransaction() undocumented

[Kosta]

The following methods of OGRLayer are undocumented: StartTransaction(), CommitTransaction(), and RollbackTransaction(). Are they new in version 1.5? What drivers implement them? Is transaction support queriable via TestCapabilities()?

[warmerdam]

Kosta,

These functions are not new for 1.5. They have been around for a while. They are intended to connect to the transaction semantics of transaction enabled RDBMSes; however, in practice they have only been implemented in one or two drivers (postgis and oracle perhaps?)

The OLCTransactions value may be passed to TestCapability() on an OGRLayer to see if it supports transactions.

Note that the transactions support on postgis is believed to be somewhat buggy, so you should use this stuff with caution.

It isn't documented because it is really still only half-baked despite having been around for several years.

[Kosta]

Frank,

due to the discussion about RFC #13, these methods should be documented nevertheless; I came up with RFC #13 because I didn't found any information about these methods. But without the transaction mechanism available you cannot get serious performance when working with the SQL based OGR drivers...

But the transaction semantics should be clearified a little bit. Questions to discuss:

1. Should there be an additional method for querying, if there is already a transaction running, something like:

   virtual bool OGRLayer::IsTransactionRunning() { return false; }
   

2. How to coupe with nested transactions? What happens, if a nested transaction should be rolled back? How should this be propagated to the outer most transaction?

3. Transactions are usually based on the database connection. But in GDAL/OGR there is only 1 connection per OGRDataSource and not 1 per OGRLayer. This could be problematic if use are working with several layers of the same data source at the same time.

4. Something else coming into my mind right after pressing the "Submit changes" button... :-)

[tamas]

Replying to Kosta:

Frank,

due to the discussion about RFC #13, these methods should be documented nevertheless; I came up with RFC #13 because I didn't found any information about these methods. But without the transaction mechanism available you cannot get serious performance when working with the SQL based OGR drivers...

But the transaction semantics should be clearified a little bit. Questions to discuss:

1. Should there be an additional method for querying, if there is already a transaction running, something like:

   virtual bool OGRLayer::IsTransactionRunning() { return false; }
   

2. How to coupe with nested transactions? What happens, if a nested transaction should be rolled back? How should this be propagated to the outer most transaction?

3. Transactions are usually based on the database connection. But in GDAL/OGR there is only 1 connection per OGRDataSource and not 1 per OGRLayer. This could be problematic if use are working with several layers of the same data source at the same time.

4. Something else coming into my mind right after pressing the "Submit changes" button... :-)

1. Since we are talking about 'short transactions' the user should keep the lifespan of the transaction as small as possible. For example he might want to use a try-finally block to control this situation and there's no need to query the current status of the transaction every time. However the various providers should keep a flag for the actual state inside and it can also be exposed to the interface.

2. AFAIK not all of the RDBMS-s support this feature so it should be handled for each datasource separately. In fact with some of the databases we can talk more about savepoints instead of nested transactions. For example PostgreSQL will provide a warning if the BEGIN statement is issued twice in the same connection. However one can define savepoints and roll back to that point at a later point. Supporting this feature would require some additional functions I think.

3. Isn't it possible to treat this issue to set up different datasources per edited layers?

4. We can think about some more:

• Support for long transactions and versioning
• Support the coordination of the transactions among various different datasources
• Support for setting up the transaction mode/isolation level
• etc.

[Jukka Rahkonen]

Seems to be undocumentet still in ​http://www.gdal.org/classOGRLayer.html. A few words about the methods can be found from the documentation of Java bindings ​http://gdal.org/java/org/gdal/ogr/Layer.html