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: Gabriel Roldán
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
