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)
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 Comment From: email@example.com - 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'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:
CodeHaus Comment From: firstname.lastname@example.org - Time: Fri, 30 Sep 2005 14:22:13 -0500
Fixed on 2.1.x;
CodeHaus Comment From: email@example.com - 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 Comment From: firstname.lastname@example.org - Time: Mon, 3 Oct 2005 15:11:05 -0500
Fixed. Added a good lock test set.