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

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

On Wednesday 21 May 2008 09:39:34 pm Jody Garnett wrote:
> 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)
it did in past, then I got with working with a single one, then introducing 
this required two again. right now you can run the ArcSDEFeatureSourceTest 
with a single connection, though I won't do any statement that a single 
connection is enough for all and every code path, yet..
The big difference is that now we have a much finer granularity on what an 
execution unit is, connection wise, so there're higher probabilities a single 
connection serves more read only operations.
>
> > 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?

ArcSDEFeatureStoreTest.testUpdateAutocommit first, then everything gets 
screwed up.

but I couldnt understand for the last long hours why the heck the command sent 
at ArcSdeFeatureWriter.getUpdatableColumnNames() (line 694) leads to this 
error and not any other command.

any clue will be much appreciated, I seem too burned right now for a single 
day, and am starting to stop beleaving in resolving hard problems in dreams 
or shower...  :)

cheers,

Gabriel

> Jody
>
> !DSPAM:4045,48347a7910434901796417!