There was a brief off-line discussion on the topic of adding the ability to specify lock-types externally (maybe via Options) such that Hibernate could simply request that "this put only acquire a read lock". Here's the key point:
"Manik Surtani" wrote : I don't think specifying lock types will work, since this is only symbolic. (i.e., with optimistic locking, locking is completely different) | | Perhaps what we need, literally, is completely separate behaviour for put() when the FAIL_SILENTLY option is used -which leads me to think that this shouldn't be an option at all, but a separate put() method - perhaps putFailFast() again, but implemented quite differently, involving all the specific needs of this put(), including: | | * suspended txs | * minimal locking | * 0 timeouts | * async replication +1 on a separate method. I'm the one who raised the original Option idea, but I think now that was wrongheaded. The term "Hibernate 2nd level cache" makes the use case sound specialized, but really it's one of the basic use cases for JBC -- read from database, then write to cache to avoid future reads. Programming for that use case needs to be dead simple; having to deal with Options is too much. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977342#3977342 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977342 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
