Task #3174 (closed)
Remove need for update lock
| Reported by: | jamoore | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | OMERO-Beta4.3 |
| Component: | Performance | Version: | n.a. |
| Keywords: | n.a. | Cc: | |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | n.a. |
| Sprint: | 2011-01-13 (3) |
Description
If SessionCache were to function similarly to a ConcurrentHashMap then modifications could be made without acquiring a lock.
Change History (10)
comment:1 Changed 13 years ago by jmoore
comment:2 Changed 13 years ago by jmoore
comment:3 Changed 13 years ago by jmoore
comment:4 Changed 13 years ago by jmoore
(In [8775/omero]) Non-blocking SessionCache version (See #3174)
This rewrite of SessionCache removes all locks in favor
of ConcurrentHashMaps and java.util.concurrent.atomic
instances. The primary difference is that read methods will
no longer wait when an update event has signaled a synchronization
is required. In the extreme case, this means that it may take
some time before old sessions are detected.
Since methods no longer have to wait after an administrative
event, sync_interval has been increased to 120 seconds from 3.
comment:5 Changed 13 years ago by jmoore
(In [8776/omero]) Only removing sessions forcibly after multiple exceptions (See #3174)
comment:6 Changed 13 years ago by jmoore
(In [8777/omero]) Removing unused try/finally block in SessionCache.internalRemove (See #3174)
comment:7 Changed 13 years ago by jmoore
- Milestone changed from Unscheduled to OMERO-Beta4.3
- Resolution set to fixed
- Sprint set to 2011-01-13 (23)
- Status changed from new to closed
Major refactoring of SessionCache has alleviated this.
comment:8 Changed 13 years ago by jmoore
(In [8828/omero]) Non-blocking SessionCache version (See #3174)
This rewrite of SessionCache removes all locks in favor
of ConcurrentHashMaps and java.util.concurrent.atomic
instances. The primary difference is that read methods will
no longer wait when an update event has signaled a synchronization
is required. In the extreme case, this means that it may take
some time before old sessions are detected.
Since methods no longer have to wait after an administrative
event, sync_interval has been increased to 120 seconds from 3.
original-svn-id: file:///home/svn/omero/trunk@8775 05709c45-44f0-0310-885b-81a1db45b4a6
comment:9 Changed 13 years ago by jmoore
(In [8829/omero]) Only removing sessions forcibly after multiple exceptions (See #3174)
original-svn-id: file:///home/svn/omero/trunk@87 05709c45-44f0-0310-885b-81a1db45b4a6
comment:10 Changed 13 years ago by jmoore
(In [8830/omero]) Removing unused try/finally block in SessionCache.internalRemove (See #3174)
original-svn-id: file:///home/svn/omero/trunk@8777 05709c45-44f0-0310-885b-81a1db45b4a6
(In [8450]) Non-blocking SessionCache version (See #3174)
This rewrite of SessionCache removes all locks in favor
of ConcurrentHashMaps and java.util.concurrent.atomic
instances. The primary difference is that read methods will
no longer wait when an update event has signaled a synchronization
is required. In the extreme case, this means that it may take
some time before old sessions are detected.
Since methods no longer have to wait after an administrative
event, sync_interval has been increased to 120 seconds from 3.