One more question though - do I understand right from the javadoc that
putForExternalRead is non-transactional? Meaning that if a change something in
a TX in the persistent store, and then call putForExternalRead with the
changes, other transactions will see the change, making it a dirty read?
Another idea, using JBC 1.4.1; for put operations, which shouldn't cause
invalidation, maybe I could use an Option with cache mode == LOCAL. For the
remove operation, I could use INVALIDATION_SYNC, which should propagate. Do you
see any obstacles here? :)
Adam
View the original post :
Hello,
well, from what I've seen in CacheHelper Hibernate is simply calling get() and
put(). However in my case this doesn't work, as I run the cache in
INVALIDATION_SYNC mode. This means that when I call put() on node1, an
invalidation message is sent to other nodes. Then, when node 2 wants to
Have a look at Hibernate, again. :-) They too use INVALIDATION, and there is
a way to deal with this - it's called putForExternalRead().
As for the CL approach, that will not work, this scenario is not what the CL is
designed for.
View the original post :
Ah yes, didn't notice it, thanks a lot! :)
Adam
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4256854#4256854
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4256854
___
jboss-user
Hello,
but if I call get() in the TX that did the changes, I want to get a
re-calculated value basing on the changed persistent store. Other threads
should get of course the old value.
Adam
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4256534#4256534
Reply
even within a TX, I would expect that if you ask for a node that is not in the
memory the cache store still to be queried and data fetched from there. Just
for me to make sure I get it right, you have something like:
tx.start()
| cache.remove(fqn); //this will clear data from both memory AND
Hello,
Well, if I call cache.remove(fqn) in a tx, then any subsequent calls return
null, without hitting the cache loader. Only after the tx is commited, the
cache loader is queried. (In the no-tx scenario it behaves as if the tx was
commited immediately after the operation.) That's what my
ah I see. Out of ideas then :(
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4256605#4256605
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4256605
___
jboss-user mailing list
anonymous wrote : Heh, I didn't expect that my use case will be so uncommon. It
seems a relatively simple idea to store some computed values and invalidate
them when the underlying data changes. But well ... :)
Well apparently this is the first time one asks for this functionality :)
One thing
Heh, I didn't expect that my use case will be so uncommon. It seems a
relatively simple idea to store some computed values and invalidate them when
the underlying data changes. But well ... :)
Adam
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4256619#4256619
Hello,
yes, I'm doing that now for a limited number of keys (eagerly putting them in
the cache instead of removing the whole node), although I'm doing it inside the
TX (I want the new values to be calculated basing on the data modified in the
TX), however I can't do that for all keys, as that
I think you are using the cache loader in an incorrect way. CLs are designed
to be a persistent (and overflow) extension to memory and should never be sued
to store a different form of data. And should also never change externally
outside the cache system.
If you want to cache stuff from a
can't you do the get call outside a transaction? You can use
TransactionManager.suspend/resume if you need to do some more work in tx after
refreshing the cache.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4256397#4256397
Reply to the post :
14 matches
Mail list logo
