Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 2.1.1, 2.2.M1
-
Component/s: shapefile plugin
-
Labels:None
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)
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. UDIG-610 and
UDIG-613are independent problems and after fixing them as I explained I get work editing of feature model and writing to shapefile..