[mapguide-internals] RE: The pinned connection (Leaf Li)

[Haris Kurtagic]

Hi Li,

I think that more work is needed for API as proposed in RFC because there is
functionality around pinning and unpinning connections and keeping track of
those. All functionality for the solution I would prefer is already there,
it is just about the way how is it exposed.

It does changes API but in same way as it changes with transaction RFC78.
My suggestion would be just to change that one and instead of adding
transaction as new parameter add connection. And then on connection just use
transaction functionality which was developed for RFC78.

Haris

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Leaf Li
Sent: Wednesday, October 21, 2009 5:44
To: mapguide-internals at lists.osgeo.org
Subject: [mapguide-internals] RE: The pinned connection (Leaf Li)

All,

Now I think we already understand the current concerns on RFC 86 very
clearly. I agree that solution what Haris proposes is clearer and more
flexible. I also want to reiterate pinned connection is an edge case that
should not be used unless it's absolutely necessary. Let's compare this
solution with current solution and then make a decision.

> Conn1 = Open(FeatureSourceId)
> Execute SQL(Conn1,..)
> Open(Conn2)
> Execute SQL(Conn2,..)
> Open(Conn3)
> Conn3.StartTransaction()
> Conn3.Committ()
> Execute SQL(Conn3,..)
> Close(conn3)
> Close(Conn2)
> Close(Conn1)

Solution what Haris proposes
Strength:
1. Clear and consistent
2. Flexible: It is possible for users to create more than one pinned
connection for a feature source in one user session. However we don't have a
requirement to create more than one pinned connection for a feature source
in one user session.
Weakness:
1. Lots of changes to API.
2. Need more efforts. Maybe we don't have enough resources to finish it in
this release cycle. If we do it in next release cycle, transaction related
API is already released. It will result in other inconsistence in next
release cycle if we can't finish it in this release cycle.

Current Solution:
Strength:
1. Small changes to API.
2. Much less effort. We can finish it in this release cycle.
Weakness:
1. Not as Clear as solution what Haris proposes. However, it works.

So now our question becomes whether we want to a perfect solution that we
may not afford or a less perfect solution that we can afford.

I think we need make a decision according to our RFC process.

If according to our RFC process we needn't vote again, Haris can continue to
vote. 
If we need vote again, let's do it again.

Thanks,
Leaf Li
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals