Re: [Geotools-devel] ArcSDE state of play [was Re: ArcSDE Single Session mode]

[Jody G. <jga...@re...>]

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