But now looking back at #1, I am no longer certain of the conclusions;
and to me the wiki did not make it clear to me what the "long term"
solution was supposed to be (nor really what the "short term" solution
is/was either). Anyone remember the specific conclusions with regards
to this point?
Long-term:
In Hibernate - use seperate caches which you have done for 3.3
In JBoss Cache - as it stands now you would have to use differnt
jbosscache configurations.
In older versions of JBC you would need different treecache.xml; but
that has been simplified
in later JBC's AFAIK - Manik/galder ? Depending on this and wether
optimistic locking is a global
or node level-and-down setting users might need some less or more
complex "writing jbosscache config files
for hibernate" examples ;)
Short-term:
Write a cacheprovider that would use different jbosscaches for each
"type" of cache.
Not sure if that still makes sense.
Manik can better comment on plans for having separate configurations
(e.g. optimistic vs pessimistic, invalidation vs replication) for
different regions of the cache. But, I know it's not a soonish thing.
ok.
That means if you want different behavior for the different "types" of
caches you need separate caches. If the JGroups multiplexer is
available, that's not too bad, as the caches can share a channel. If we
think it through well, they can likely share an overall config file,
with the different "types" just overriding a couple properties that are
relevant.
sounds good. Could you provide an good default fallback setup for
hibernate to run with ?
If the JGroups multiplexer isn't available then having a separate cache
for each "type" is a royal pain, since you have multiple channels that
need to have unique ports, etc. And we need to assume that the
multiplexer won't be available in any non-JDK5 env, since the earliest
JG release where it's reliable is 2.5.
So I guess we just won't have good jbosscache integration before 2.5;
similar that
it won't work good before Hibernate 3.3. Is that a problem ?
Re: #4 : what exactly are these differences? Now is the time to merge
it back...
I recall these as being Bryan 2 things:
1) setting up JBC/Cacheprovider so it would use the correct
classloader when loading data from the cache.
2) doing some "mutations"/magic-lookup of the cache region names to
know which classloader to use
(this might just me having nightmares, so need Bryan to certify ;) If
it's true we would
need to look into the practicallity of that solution.
The issue here is that if you send a message to replicate type Foo, on
the remote node the thread coming up from JGroups that handles the
message needs access to the Foo class in order to deserialize Foo and
put it in the cache. Determining the correct classloader to use is a
problem if the cache is shared between multiple deployments. There's a
standard JBC API to handle this use case, as discussed at
http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.1/TreeCache/en/html/treecache_marshaller.html.
I understand that part.
The fix I did was just to 1) have the org.hibernate.cache.Cache impl
make use of this API and
Got it.
2) prevent replication of the org.hibernate.cache.StandardQueryCache
region, since that region could be shared between multiple deployments
and hence there's no 'correct' classloader.
eh - ok, sounds bad.
Isn't it better to just use hibernate.cache.region_prefix to disambiguate
the regions per sessionfactory ?
I don't think querycache region is the only one that would have problems
if you are using the
same physical cache for multiple sessionfactories. e.g. if a
org.company.model.Customer exists in both you would have troubles
with the entity cache.
If we move to a mode where we have one cache (or set of caches) per
deployment, then this kind of stuff becomes unnecessary. But, again,
that requires the JGroups multiplexer.
Today you should not use the same cache across deployment; that's a big
nono.
The separation of caches has more to do with having different semantics
with respect
to replication, locking and put/remove operations.
Re: #5 : what about the other solution I proposed where instead of
registering synchs directly with the TC/TM, you instead delegate it to
a strategy which can route the request back through Hibernate;
Hibernate can then manage ordering the callbacks?
I don't recall more progress on that topic.
Don't forget this one - manik ? :)
/max
/max
Re: #6 : I'm actually in favor of just moving to the new (2.0) API;
easier from a management perspective.
Ok, so my notes from the call, based on issues from the wiki
1. Multiple caches will probably only formally make it in the next
major Hibernate release - 3.3.
2 Notes on putForExternalRead() functionality, in addition to the
solution presented on the wiki:
- PFER only goes through if node does not exist; no-op otherwise
- Force asynchronous mode for replication or invalidation to prevent
any blocking
- 0ms lock timeout to prevent any blocking here either. If this
fails, PFER is a no-op
- no to separate thread necessary, since we will be operating with a
0ms timeout, async replication and a no-op if the node exists. The
only real chance of any blocking here is JGroups FC which is
considered small enough a case.
3. Since JBC 1.4.1.SP1, write locks are not acquired on parents when
adding or removing children, to be more accurate to repeatable read
semantics. WLs can still be acquired on parents if enabled in the
configuration (see "LockParentForChildInsertRemove" in
http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.1.SP2/TreeCache/en/html/configuration.html,
which defaults to false). As such, this contention should no longer
be a problem.
4. Brian implemented for EJB3 clustering in AS 4.2, will make it's
way back into HIbernate in the 3.3 timeframe?
5. Do nothing for now since the urgency is removed. Only fails on
old versions of JBoss TS. In future (JBC 2.1 timeframe) look at what
the microcontainer has to offer with synchronisation registrations.
6. Coordination issue
7. Galder to come back with more details here, but general consensus
is not to perform transparent retries.
Feel free to add stuff I may have missed or further thoughts.
Very useful and productive call!
Cheers,
Manik
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss a division of Red Hat
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev