[fdo-internals] Motion: RFC 3 - PostGIS provider

[Orest Halustchak]

I don't think that save points would work the way we'd expect a regular
transaction to work. A save point is within a transaction and while you
can roll back to a save point, you can't really commit at a save point
except by committing the transaction that includes it.

Again, we're talking about short transactions in this case, not long
transactions.

Basically, fdo expects the standard short transaction mechanism. It's
not a nested transaction concept. You can execute any set of data update
operations and they will be isolated from other users until a
transaction commit. At that time, the edits are permanent and other
users can see them. A rollback will remove all edits done since the
beginning of the transaction. A short transaction supports ACID
properties (atomicity, consistency, isolation, and durability).

Thanks,
Orest.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Tuesday, May 08, 2007 12:38 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Motion: RFC 3 - PostGIS provider

Jason Birch wrote:

> PostgreSQL doesn't currently support nested transactions.  Mateusz has

> been using "soft" transactions internally to ensure per-action 
> consistency, so if we support explicit transactions he will have to 
> somehow test for existing transaction before starting internal 
> transactions.

Not knowing how FDO is actually exercising the database or what contract
it expects, I will blindly ask: is it possible that savepoints do what
FDO needs done?

http://www.postgresql.org/docs/8.0/interactive/sql-savepoint.html
-- 

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   pramsey at refractions.net
   Phone: 250-383-3022
   Cell: 250-885-0632
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals