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? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861893#3861893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3861893 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
