Re: [Geotools-devel] arcsde datastore queue and questions

[Gabriel R. <gr...@op...>]

On Tuesday 15 April 2008 03:43:07 am Jody Garnett wrote:
> Gabriel Roldán wrote:
> > Hi Jody,
> > Cool, go with my bless (and peer review).
> >
> > On Tuesday 15 April 2008 02:19:15 am Jody Garnett wrote:
> >> So I have started in on gabriel arcsde design work; as per todays IRC
> >> discussion I am going to send emails to the devel list for everyone to
> >> ignore equally....
> >>
> >> I have started by making ArcSDEPooledConnection wrap an SeConnection
> >> (rather than extend it). The result makes a lot of sense; since this
> >> class is really taking responsibility for isolating an SeConnection from
> >> a multi-threaded world. I am not modifying the use of a lock right now;
> >> only adding enough methods so everything can work.
> >
> > okay makes sense. Are you going to work strictly on trunk? do you plan to
> > backport to 2.4?
>
> I gotta get this working on trunk; if there is any money/time left over
> I could checkout 2.4.x and backport - this is your call as module
> maintainer? How would you like me to spend my time...
spend it doing it well and let me backport :)
>
> >> I did have a question; when passing out an object like new
> >> SeTable(connection, qualifiedName); does the created SeTable hold on to
> >> the connection forever? Ie is the SeTable only valid as long as the
> >> connection is open?
> >
> > Yes, its kept as an SeTable member field afaik. So its not that a good
> > idea to cache SeTable/SeLayer. Yet some time ago we did that at the pool
> > level when Brock A. were having performance issues for a client. To
> > alleviate that I added getTable(String name) to ArcSdePooledConnection,
> > so the table referencing the connection keeps close to the connection,
> > but still am not too happy with that.
>
> I see; so I could hose out the cache if the connection goes down. Good
> to know; darn I hate information hiding violations. What do you think of
> "leased" objects; we could even make several "runnables" that are passed
> SeTable / SeLayer etc... that are valid until the runnable is closed.
>
> Asked another way; it is okay if the ArcSDEPooledConnection holds onto
> these data structures; it is bad if any code under user control tries to
> hold onto instances that store a connection outside of our control.
> Because if SeTable is going to use that connection I want it only to act
> from within one of these "tasks" in order to prevent multiple threads
> using the connection at once.
Exactly.
We have to options.
a) understand the usage of SeTable and SeLayer shall be limited to the bounds 
of the runnable. That is, no "client" code shall ever hold a SeTable/Layer on 
its own, and we do that as convention since its our module.
b) abstract out the whole ArcSDE API and provide our own facade for the whole 
thing

I though of b) a couple times but never had the energy, nor you'll have on 
this run.

btw, what's your timeframe for this?

Gabriel
>
> Jody
>
> !DSPAM:4045,4804082b67621431913854!