Gabriel Roldán wrote: > 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 > Sounds good. > 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. > I will update 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. > That is confusing to me; I don't understand it either. > 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.. > This is why I need the code review: - ArcSDEConnectionReference.issueReadCommand will try and reuse the "last" Session (ie the only session), if it is not available it will grab a Session from the pool like normal -ArcSDEConnectionPool.issueReadCommand will grab a session from the pool like normal - I did not want to change any functionality on you until you had done a code review. So this method behaves exactly the same as before (ie we always needed 2 connections in the past) > 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. > So where does the exception about threading appear? Jody
------------------------------------------------------------------------- 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
