This is a tough problem as we have no good way to preserve encapsulation.
It would be nice to InProcessLockingManger check writer implemented an
interface, or had some extra state we could set, allowing it to know we
were at then end of a commit.
Getting access to an "unwrapped" writer from ContentDataStore will also be
tricky as the exact wrappers that have been applied depend very much on
format being implemented.
Since this problem surfaces in the middle of DiffTransactionState.commit()
we should see if we can handle any shenanigans there. Is there any way for
this commit method to obtain a new writer (with both a diff writer and a
lock writer in the mix) and carefully disable (i.e. pass through any
changes) that would otherwise be stored in memory.
--
Jody Garnett
On 5 January 2015 at 16:32, Torben Barsballe <[email protected]>
wrote:
> In attemting to provide the writer with the correct transaction, I ran
> into a number of test failures relating to transaction independance. While
> I have not thoroughly traced these failures, this suggests that using the
> same method as AbstractDataStore (an unwraped internal writer) may be the
> best course.
>
> Torben
>
> On Mon, Jan 5, 2015 at 4:16 PM, Torben Barsballe <
> [email protected]> wrote:
>
>> With the new implementation of PropertyDataStore(extending
>> ContentDataStore), I am getting test failures for most of the Geoserver WFS
>> Locking tests. I was able to determine that this is being caused by
>> transactions not correctly releasing their locks, which in turn is caused
>> by a failure in the DiffTransactionState.commit() method:
>>
>> In DiffTransactionState.java: line 135-140:
>>
>> if (source instanceof ContentFeatureStore) {
>> store = (ContentFeatureStore)
>> dataStore.getFeatureSource(name);
>> writer = store.getWriter(Filter.INCLUDE);
>> } else {
>> throw new UnsupportedOperationException("not writable");
>> }
>>
>> Here, we get a writer from ContentFeatureStore. The store is not provided
>> with a transaction, such that both the store and the writer use
>> Transaction.AUTO_COMMIT.
>>
>> When we go to write the data, the call to writer.write() passes through
>> InProcessLockingManager.assertAccess(), which fails because we are using
>> Transaction.AUTO_COMMIT rather than the transaction of the
>> DiffTransactionState
>>
>> The previous implementation in AbstractDataStore gets around these checks
>> by using the internal writer (In this case, PropertyFeatureWriter) with no
>> wrappers, thereby bypassing InProcessLockingManager.
>>
>> I am currently working on a potential fix for this issue by injecting the
>> correct transaction into the writer, but any input on the best way to
>> proceed is welcome.
>>
>> Torben
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
