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... >> 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. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
