2 Replies Latest reply on Jul 11, 2006 5:19 AM by Simon Godden

    Read-Mostly entities with CMR

    Simon Godden Newbie

      We 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?