|
If you were logged in you would be able to see more operations.
|
|
Elmo
Created: 02/Sep/06 06:24 PM
Updated: 02/Sep/06 08:06 PM
|
|
| Component/s: |
Object Model
|
| Affects Version/s: |
0.2
|
| Fix Version/s: |
0.3
|
|
In Elmo, we have the following core classes:
ElmoRepository is a thin wrapper of SesameRepository. It exposes the same methods as SesameRepository plus adds two things: caching for repository objects and an own listener mechanism (ElmoRepositoryEvent and ElmoRepositoryListener).
ElmoSession is a bit more extensive wrapper around an ElmoRepository that allows to manipulate data at the ontology level. (This is the main class of Elmo basically.)
The deadlock occurs when
-- one thread is reading the repostory through a JavaBean
-- another thread is writing it through ElmoRepository
The tricky thing is that while ElmoRepository and SesameRepository can be properly synchronized on their own, there can still be a race between them when
-- the first thread is in the getCacheMap method of ElmoSession trying to read the repository
-- the second thread has modified the repository and trying to notify the ElmoSession
In this case the first thread is holding the lock to the ElmoSession and the second is holding the lock for the Repository. They are waiting for the each other and the result is a deadlock.
I found and fixed this bug myself but thought it is interesting enough to document.
|
|
|
Change by Peter Mika [02/Sep/06 06:27 PM]
|
| Field |
Original Value |
New Value |
|
Description
|
In Elmo, we have the following core classes:
ElmoRepository is a thin wrapper of SesameRepository. It exposes the same methods as SesameRepository plus adds two things: caching for repository objects and an own listener mechanism (ElmoRepositoryEvent and ElmoRepositoryListener).
ElmoSession is a bit more extensive wrapper around an ElmoRepository that allows to manipulate data at the ontology level. (This is the main class of Elmo basically.)
The deadlock occurs when
-- one thread is reading the repostory through a JavaBean
-- another thread is writing it through ElmoRepository
The tricky thing is that while ElmoRepository and SesameRepository can be properly synchronized on their own, there can still be a race between them when
-- the first thread is in the getCacheMap method of ElmoSession trying to read the repository
-- the second thread has modified the repository and trying to notify the ElmoSession
In this case the first thread is holding the lock to the ElmoSession and the second is holding the lock for the Repository. They are waiting for the each other and the result is a deadlock.
I found and fixed this bug myself but thought it is interesting enough to document.
|
In Elmo, we have the following core classes:
ElmoRepository is a thin wrapper of SesameRepository. It exposes the same methods as SesameRepository plus adds two things: caching for repository objects and an own listener mechanism (ElmoRepositoryEvent and ElmoRepositoryListener).
ElmoSession is a bit more extensive wrapper around an ElmoRepository that allows to manipulate data at the ontology level. (This is the main class of Elmo basically.)
The deadlock occurs when
-- one thread is reading the repostory through a JavaBean
-- another thread is writing it through ElmoRepository
The tricky thing is that while ElmoRepository and SesameRepository can be properly synchronized on their own, there can still be a race between them when
-- the first thread is in the getCacheMap method of ElmoSession trying to read the repository
-- the second thread has modified the repository and trying to notify the ElmoSession
In this case the first thread is holding the lock to the ElmoSession and the second is holding the lock for the Repository. They are waiting for the each other and the result is a deadlock.
I found and fixed this bug myself but thought it is interesting enough to document.
|
|
Change by Peter Mika [02/Sep/06 06:28 PM]
|
| Field |
Original Value |
New Value |
|
Component/s
|
|
Object Model
[ 10080
]
|
The current resolution is that the thread reading the repository through ElmoSession is releasing the lock of the ElmoSession when reading the repository. An alternative solution would be if Sesame's SynchronizationSail would release the lock of the repository first and only then try to notify listeners of changes.
|
Change by Peter Mika [02/Sep/06 06:30 PM]
|
| Field |
Original Value |
New Value |
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
|
Fix Version/s
|
|
0.3
[ 10228
]
|
|
Resolution
|
|
Fixed
[ 1
]
|
|
Change by Peter Mika [02/Sep/06 08:06 PM]
|
| Field |
Original Value |
New Value |
|
Status
|
Resolved
[ 5
]
|
Closed
[ 6
]
|
|
|
Bug
Closed
Major
Deadlock when separate threads are manipulating the same ElmoRepository