[mapguide-internals] RE: The pinned connection (Leaf Li)
Leaf Li
leaf.li at autodesk.com
Tue Oct 20 23:44:00 EDT 2009
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
More information about the mapguide-internals
mailing list