[jboss-user] [JBossCache] - Re: Hibernate/Cache conceptual mismatch

[bstansberry@jboss.com]

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