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

[Jason Birch]

I think that if the provider was set up to maintain an outer transaction
on a per-connection basis this might work.  However, it would mean that
nobody else would see any updates until the connection was closed (and
the transaction ended).  This wouldn't work too well with cached
connections in MapGuide

I also don't know how transactions are used in FDO; if they're
established with an explicit call to the provider, and then maintained
for the entire connection until the connection is closed (roll back) or
the transaction is manually rolled back or committed?  Again, how would
this work with MapGuide?  With cached connections, what happens when
transaction requests overlap?

I don't think that most of my use cases (feature update via the web)
would benefit from explicit transactions.  I think that in general,
users expect single operations (delete a bunch of features,
update/insert a bunch of features) to commit when they are finished.

Jason 

-----Original Message-----
From: Paul Ramsey
Subject: Re: [fdo-internals] Motion: RFC 3 - PostGIS provider

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