Deadlock during committing changes to shapefile

Description

Committing changes to shapefile (features are added or modified) leads to dead lock!
The reason is two synchronized methods in TransactionStateDiff class from GeotTools API
while one thread performs committing, another thread tries to render shapefile datasource.
The following chain of events happens:

1) rendering thread gets ShapefileReader and locks Lock object from shapefile API in reading mode
2) committing thread tries to get lock for writing and waits in cycle in Lock object infinitly
3) call stack of committing thread goes through TransactionStateDiff.commit() method and locks that object for calling synchronized methods from other threads
4) rendering thread tries to get into TransactionStateDiff.diff() method but it is blocked until committing thread gets write access from Lock object.

We get infinite rendering progress indicator inside of UDIG and infinite committing.

Sometimes committing changes doesn't lock, but 95 % it locks (tested on different machines)

Environment

None

Activity

Show:
codehaus
April 10, 2015, 3:00 PM

CodeHaus Comment From: vitalus - Time: Tue, 6 Sep 2005 14:25:38 -0500
---------------------
So, the straightforward solution, I recompiled geotools-main module where TransactionStateDiff.diff() method is not synchronized anymore - it solves this deadlock problem perfectly

What is the reason that this method is synchronized? in UDIG it leads to deadlock while committing as I explained because of multithreaded renderers..

If this method should be synchronized , other workaround has to be found in UDIG..

P.S. <a href="https://jira.codehaus.org/browse/GEOT-698" title="Deadlock during committing changes to shapefile" class="issue-link" data-issue-key="GEOT-698"><strike>UDIG-610</strike></a> and <a href="https://jira.codehaus.org/browse/UDIG-613" title="Deadlock during committing changes in shapefile data store" class="issue-link" data-issue-key="UDIG-613"><strike>UDIG-613</strike></a> are independent problems and after fixing them as I explained I get work editing of feature model and writing to shapefile..

codehaus
April 10, 2015, 3:00 PM

CodeHaus Comment From: jeichar@refractions.net - Time: Fri, 30 Sep 2005 13:56:19 -0500
---------------------
I improved the lock implementation to take into account the current thread it has fixed the problem. The problem occurred when a thread obtained the lock in write and read mode and doesn&#39;t release in the correct order. Also if the read lock is obtained first by the thread before the write lock then a dead lock occurred.

this is fixed on trunk:

revision: 15967

codehaus
April 10, 2015, 3:00 PM

CodeHaus Comment From: jeichar@refractions.net - Time: Fri, 30 Sep 2005 14:22:13 -0500
---------------------
Fixed on 2.1.x;

revision: 15968.

codehaus
April 10, 2015, 3:00 PM

CodeHaus Comment From: jeichar@refractions.net - Time: Fri, 30 Sep 2005 21:01:24 -0500
---------------------
Still some bugs I am fixing them. (I also had to modify transaction state diff)

codehaus
April 10, 2015, 3:00 PM

CodeHaus Comment From: jeichar@refractions.net - Time: Mon, 3 Oct 2005 15:11:05 -0500
---------------------
Fixed. Added a good lock test set.

Assignee

Unassigned

Reporter

codehaus

Triage

None

Components

Fix versions

Affects versions

Priority

High
Configure