[fdo-internals] Motion: RFC 3 - PostGIS provider
orest.halustchak at autodesk.com
Tue May 8 14:29:42 EDT 2007
I expect that the use of transactions would be mostly for desktop
One thing that we don't want is a transaction left open waiting for an
end user to perform an action.
However, an edit MapGuide application could include a server script that
makes an integrated set of edits that is done as a transaction, e.g. a
single user action such as hitting a button could cause a server script
that starts a transaction, executes a number of edit operations such as
delete one feature, move another, add a third, and then does a commit.
This whole action would be done via one connection. The connection can
be given back to the pool after this operation is done.
The transaction capbility is there in the api for application developers
that need to be able to control transactions within the scope of their
application. Without transaction control an application couldn't define
an atomic operation that is made up of a set of separate commands.
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Tuesday, May 08, 2007 1:34 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Motion: RFC 3 - PostGIS provider
I'm still not clear on how/if transactions could work with MapGuide
given how connections are cached and, with statelessness and the way
that MapGuide proxies database connections as a single user, whether
they would work even if connections weren't cached.
Is the requirement for transactions driven by desktop application use
From: Paul Ramsey
Subject: Re: [fdo-internals] Motion: RFC 3 - PostGIS provider
In that case, PostgreSQL has all the facility needed to support the FDO.
Orest Halustchak wrote:
> You can execute any set of data
> update operations and they will be isolated from other users until a
> transaction commit.
fdo-internals mailing list
fdo-internals at lists.osgeo.org
More information about the fdo-internals