When I've contrasted put() and update() I've been using the Hibernate cache terminology put() - cache fill (== putFromExternalRead()) - update - database change (== put()). I don't think a putFromExternalRead() would normally cause a "dirty read", but one possible interpretation of Scott's question was what would happen if you called putFromExternalRead() with data that wasn't yet committed to the database.
I don't know why the asynchronous replication of putFailFast() was added orginally, but my assumption is that it's about increasing concurrency and performance. Replicating cache fills synchronously doesn't increase correctness, so you might as well do it synchronously.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977566#3977566
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977566
Just to clarify my last comment. Keep in mind that putFromExternalRead() always results from the following usage pattern:
Object state = readFromCache();
if ( state == null ) {
state = readFromExternal();
putIntoCache( state );
}
...
In Hibernate terms, readFromExternal is causing the data to get read from the database because it was not found in the cache. That db-read data is always the "truth" in a db-driven app...
The only way that data should not overwrite the current node data (putIntoCache) is if suddenly there has been a write lock applied to the node between readFromCache() and putIntoCache() being executed (which is the meaning of my "intention lock" comment).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977563#3977563
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977563
Owen: (1) What is your deliniation of "put" and "update"? (2) I don't follow how a put could result in a dirty read...
Another possibility to consider is an "intention lock" where we temporarily lock a node for the duration of the read/putFromExternalRead cycle. This would guarentee two threads from attempting the same process. This would be instead of #2...
So what was the reason for forcing asynch replication? Why not synch? I did not follow where that came in at.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977561#3977561
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977561
Where are placing the remote and home interfaces of your beans. Is it in two separate locations(once in war and once in a jar)? If yes, then maintain it at only one place and remove those interfaces from the war.
Have a look at:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingOverview
Here's an extract from the same:
anonymous wrote : I get ClassCastException
|
| Assuming it is the same class name, this problem relates to classes getting loaded from different classloaders. At compile time your class has only one identity, its name. If you "deploy" a class many times in different jars, it has multiple identities. They are not the same. See below for more information on the solutions to this problem.
|
| This can also be caused by you only redeploying part of your application. e.g. a webapp uses an EJB and you only redeploy the EJB. The webapp will still have the old versions of the classes.
Also, look at:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassCastExceptions
Specifically, the jmx-console method mentioned over there
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977558#3977558
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977558