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

Haris Kurtagic haris at sl-king.com
Wed May 9 03:20:30 EDT 2007


Hi,

If I understand correctly than long transactions in MG would not work
well?
User put one connection into long transaction and then connection goes
to pool and connection get assigned to another user ?

Anyhow having connection pooling done inside MG is something I was
thinking about couple times.
I am thinking that caching should go on in the middle (FDO - for
providers not supporting caching) or leave it to provider.

Also to be able to assign FDO/RDBMS connection to authenticated user in
MG is very important, especially if I look at MG as editing tool.

Haris

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest
Halustchak
Sent: 8. maj 2007 20:30
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Motion: RFC 3 - PostGIS provider

Hi Jason,

I expect that the use of transactions would be mostly for desktop
applications.

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.

Thanks,
Orest.

-----Original Message-----
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
only?

Jason

-----Original Message-----
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
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals


More information about the fdo-internals mailing list