Read-Mostly entities with CMR
sgodden Jan 13, 2005 4:25 AMWe are using entities where the majority of the time, they are simply
being read, with the occasional update that must be immediately
reflected in any threads using the entity(s). Since we don't want to be
using dirty data in the entity, we need (or at least, we think we need)
to use a suitable locking policy. A caveat of the procedure is that
multiple clients may access the entity data at one time, including the
entity's composed entities.
We started development using QueuedPessimisticEjbLock locking. This
guaranteed that the data was correct, but the length of queue time for
requests seemed to increase in-line with the number of clients.
Additionally, since the query methods were not returning the entities in
the same ordering, deadlocks were frequent. Since marking methods
read-only does not enroll the calls in a transaction, the use of dirty
data seems possible.
We then started using two deployed entities, one of which was marked
read-only, and one normal. We used cache-invalidation and grouping to
ensure that when one bean was changed, the others were invalidated and
re-read. The problem with this seems to be dirty data when the read-only
bean is being brought in whilst the read-write bean is writing out it's
data. Plus, this method does not seem to be supported on any of the
other target platforms.
Recently, we have experimented with SimpleReadWriteEjbLock. This seems
to allow us to do what we want, except for one minor problem - the CMR.
When we retrieve the associated entities, sometimes we want to update,
add or remove those entities, and other (most) times we just want to
look through them. If we mark the method as read-only, then we cannot
modify the Collection. If we do not mark it, then the majority of the
reads will request a promotion to write lock, even when only reading is
desired - resulting in a large number of (unneccesary) Rollbacks.
Has anyone else been in the situation described above - read-mostly with
CMR - and found a solution they consider adequate? Or, is the situation
described above better tackled in a different manner entirely?