[
http://jira.codehaus.org/browse/GEOT-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jody Garnett reopened GEOT-1582:
--------------------------------
Nope I screwed it up ... had not accounted for the if/than/else statement that
would only make a new transaction if it found a transaction state diff to
replace; for the simple case of a *null* no ArcTransactionState was created.
Going to leave it open until I get a confirmation.
> ArcSDEDataStore in conflict with super class over TransactionState
> ------------------------------------------------------------------
>
> Key: GEOT-1582
> URL: http://jira.codehaus.org/browse/GEOT-1582
> Project: GeoTools
> Issue Type: Bug
> Components: data arcsde
> Affects Versions: 2.5-M0
> Reporter: Jody Garnett
> Assignee: Saul Farber
> Fix For: 2.5-M0
>
>
> I just ran into the following issue (when working with an empty table - don't
> ask):
> {panel}
> java.lang.ClassCastException:
> org.geotools.arcsde.data.ArcTransactionState cannot be cast to
> org.geotools.data.TransactionStateDiff
> at org.geotools.data.AbstractDataStore.state(AbstractDataStore.java:466)
> at
> org.geotools.data.AbstractDataStore.getFeatureReader(AbstractDataStore.java:361)
> at
> org.geotools.data.DefaultFeatureResults.reader(DefaultFeatureResults.java:205)
> at
> org.geotools.data.store.DataFeatureCollection.openIterator(DataFeatureCollection.java:218)
> at
> org.geotools.data.store.DataFeatureCollection.iterator(DataFeatureCollection.java:188)
> at
> org.geotools.renderer.lite.StreamingRenderer.processStylers(StreamingRenderer.java:1586)
> at
> org.geotools.renderer.lite.StreamingRenderer.paint(StreamingRenderer.java:648)
> at
> org.geotools.renderer.lite.StreamingRenderer.paint(StreamingRenderer.java:480)
> {panel}
> A code review shows the following:
> {panel}
> // Well, this seems to come prepopulated with a state object,
> // but I can't seem to figure out why. As such we check for
> // and existing state, and check that states class as well. If
> // it is a state we already provided (or at least of a workable
> // type) then we will proceed with it. Otherwise, we must remove
> // the state and replace it with an appropriate transaction
> // state object that we understand. This should not present any
> // danger as the default state could not possibly have come from
> // us, and as such, no uncommitted changes could be lost.
> {panel}
> So it looks like we have an honest conflict; the super class wants to store a
> TransactionStateDiff using *this* as a key; and
> the ArcSDE subclass wants to store a ArcTransactionState using the same key!
> The quick fix is to use *connectionPool* for the key; I have isolated this
> into a method getArctransactionState( transaction )
> so we can experiment with this in the future.
> The long answer is that the contract with the parent is not a good one; the
> JDBC DataStores went off and did their own thing - perhaps it is
> time for ArcSDEDataStore to stand on its own?
> To help keep things under control I made the
> *AbstractDataStore.state(transaction) method protected; so ArcSDEDataStore can
> return *null* (to indicate that it is manging transaction isolation on its
> own). This is not a perfect fit; many of the hacks applied to
> AbstractDataStore for depend on being able to play with the diff and interact
> with it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
