Hey Jody, so this is what I did: - got rid of connection.commit/rollback in ArcTransactionState - added ArcSDEDataStore.getSession(Transaction). For read only use just call it with Transaction.AUTO_COMMIT, and that's what FeatureSource does, whilst FetureStore uses the transaction it was set with
There's something strange with the command execution though, may be you have some time to test it, since its almost bed time for me now. The strange is that running ArcSDEFeatureStoreTest against my server (which is close so it runs fast) I get a lot of "THIS CONNECTION IS BEING USED AT THE MOMENT BY ANOTHER THREAD" errors, while executing the same test against your server ( which is far away so most of the time is spent in network io) only the last two test cases fail. My hope is that if you run it you'll get a lot of broken cases as your server is fast for you, and you may be able to get a clue why some command execution is breaking that way... Another thing: using issueReadCommand like you did in fetchSchema implies needing two connections at a given time for a single thing. I've commented it by now, since I guess when using ArcSDEConnectionReference you just want to return the same session over and over, so there shouldn't be a need to do anything special? or rather I'm not understanding why you want the issueReadOnly method. The idea being to pick up any available connection, but you have only one, so why not just overriding getSession to return the same one? not sure.. Also, you'll note a lot of verbosity on the console, it was me freaking out while trying to understand about what's causing the connection to complain about threading. On Wednesday 21 May 2008 07:28:20 pm Jody Garnett wrote: > Gabriel Roldán wrote: > > Okay I took my time to review... yet I'm still confused. > > > > besides getting a lot of test breakages due to NPE when asking for the > > Session from the state, my concerns are as follow: > > > > I understand the responsibility breakdown you made between > > ArcTransactionState and SessionTransactionState, but right now we have: > > - both Transaction.State implementations commiting/rolling back the > > connection - The transaction commit and the version handling shall be > > handled atomically. Having them handled at different places (the two > > states) gives us no way of knowing the order they will be executed in, > > they'll be called by Transaction.commit > > Only the SessionTransactionState should be handling commit/rollback, > lets fix this. It seems I did not get the responsibilities correct. > > > Still, ArcTransactionState having too much responsibility is annoying. > > For instance: > > x commiting/rolling back the transaction over the Session > > - issueing edit events > > - handling version states > > Can we just remove the one marked "x" above? > > > but I don't see a clear escape route. > > > > What I do see is access to Session and State quite convoluted, so my plan > > is as follows: > > - only ArcSDEDataStore knows of ArcSDEConnectionPool, holds it as an > > instance variable > > Okay; we also have some raster classes that use ArcSDEConnectionPool right? > > > - Add ArcSDEDataStore.getSession(Transaction) as the only way of getting > > at a session from the objects it creates (FeatureSource and store) > > What about a FeatureSource on Transaction.AUTO_COMMIT ? > > > - Short lived objects (ArcSDEAttributeReader and ArcSDEFeatureWriter) > > receive the Session they work on as well as the Transaction. When they're > > done (ie close()) calls ArcSDEDataStore.dispose(Session, Transaction), > > which knows whether to return the session to the pool or not. > > We can also make a Session wrapper; that calls dispose( Session, > Transaction ) so that ArcSDEAttributeReader / ArcSDEFeatureWriter do not > have to be complicated further. > > > This is meant to avoid some logic duplication, hiding ArcTransactionState > > and avoid ArcTransactionState from creating itself. I may be missing > > something though, but all in all it seems to me those actions will > > provide for some more clean up. thoughts? > > I am still wanting feedback on my problem / solution; namely can you > review how getSchema( typeName is handled) - that is the point of the > changes you saw yesterday :-) > Jody > > !DSPAM:4045,48345bb4257492090977483! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
