Re: [hibernate-dev] [jdf-dev] JBoss Modules dependency vs pain POM dependency + exclusions
other module that provides an impl of the Hibernate 2LC SPI. That module shouldn't export Infinispan, etc. Same pattern should apply to any of the standard uses of Infinispan in WF. >>>> Also it adds additional constrains when deploying the app server and app. >>>> It is not just about dropping in a ear/war >>>> anymore, suddenly I have to "patch" my app server first. >>> >>> Right I see your point on this: if it feels like patching it doesn't >>> look good. But it feels much better if you look at it as "dependency >>> resolution". >> >> How can it feels better by just naming it something else. What counts is >> that I have to >> install a default AS instance and then modify/patch its inner configuration. > > We always do modify the AS server when deploying an app or configuring > it in any form, still I never tell the top manager we're going to > initiate an open hearth surgery on their IT system :D > Such a terminology would only appropriate in some quite specific > contexts right? So let's not pick the wrong name: I don't think that > adding a jar to the place it is designed to be, in an appropriate > extensions directory, is "patching" nor has much to do with inner > configuration. > >>> I can totally see how a wildfly instance could download >>> these on-demand from the dependency definition; by having these in >>> Maven, corporate environments might not dislike it too much as they >>> could have their own repository managers. >> >> Now that is different imo. Now we provide some proper tooling around this. >> When are you having this ready to go? > > I think we could ask for help to make better tooling, if we have a > case. We won't get tooling to deploy modules if we don't make the > modules and verify this is a good plan. Ideally I'd like WildFly to > automatically download extensions, so we can blame the app server for > "downloading the internet" :) > As mentioned above, this kind of thing is under consideration for the long term roadmap. >>> BTW this problem is only for JBoss / Wildfly as other app servers >>> don't bundle Hibernate, so the solution is special purpose as well. >> >> So basically we are saying on our app server it is actually harder to get >> this to work than on >> others. Interesting. Maybe we should target Glassfish then. > > We should target them all, including WildFly even if it needs an > additional zip :-) > BTW only WildFly would be able to address the monitoring, Infinispan > and mod_cluster integrations appropriately, at least until others > won't expose similar capabilities and modularity. > > -- Sanne > >> >> --Hardy >> -- Brian Stansberry Principal Software Engineer JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 3.5.0-CR-2 set up in JIRA
Galder found a flaw in the fix for http://opensource.atlassian.com/projects/hibernate/browse/HHH-3817 that affects second level caching with both JBoss Cache and Infinispan. I'm working on a fix that I plan to finish by the 23rd at latest (goal is tomorrow.) On 02/16/2010 03:56 PM, Steve Ebersole wrote: > Just wanted to point out to everyone that 3.5.0-CR-2 has been set up in > JIRA ( > http://opensource.atlassian.com/projects/hibernate/browse/HHH/fixforversion/11011 > ) and tentatively scheduled for Feb 24 2010. I say tentatively because > I am not sure I will wait that long; lets see how things go. > > In the meantime, I moved all unresolved issues not in progress to 3.5.x. >Please take the time asap to mark any issues you want in 3.5.0-CR-2. > I completely expect this to be the last CR before 3.5.0 > > Thanks > -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [jboss-dev] Solution for failing Isolated query cache tests in Hibernate trunk
Hmm, I think I may have dropped something in translation when I ported this test from the JBoss AS/EJB3 testsuite. These tests originate in AS tests that check whether the JBC 2nd level cache integration handles cases where the "key" Hibernate passes as a param to cache write operations uses custom types. That is: 1) The primary key for a cached entity is not a simple JDK type but a custom type. 2) The params for a cached query involve custom types. At least in the past, those keys were not serialized, they were the unserialized objects. And since they are keys the Region impl can't manipulate them in ways that may effect equals/hashcode, so it just stores them directly in the cache. Doing that can cause problems on remote nodes (remote node can't deserialize a replication message) unless the Region impl has taken steps to ensure JBC/Infinispan knows how to find the correct classloader to use. That's what the original tests were meant to be testing. Looking briefly at this one today though, it looks like my porting job messed up; the custom type here is just an ordinary field in the entity (not the primary key) and isn't used as a param in any cached queries. On 01/14/2010 01:23 PM, Steve Ebersole wrote: > Also, you seem to have a quite elaborate functional test that simply > checks whether SerializationHelper is able to handle deserialing a class > from an "isolated classloader" via the SerializableType. Couldn't we > just have a simple unit test that asserted exactly that? > > > On Wed, 2010-01-13 at 20:25 +0100, Galder Zamarreno wrote: >> >> On 01/13/2010 07:10 PM, Steve Ebersole wrote: >>>> For completion, getReturnedClass().getClassLoader() will always return >>>> null because SerializableType is initialised with java.io.Serializable >>>> as returned class, and it's classloader returns null (quite likely cos >>>> it's a system class?). >>> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getClassLoader%28%29 >>> >>> null generally indicates the loader is the "boot loader". >>> >>> The nullness itself is not an issue, the issue is the lack of >>> visibility. >>> >>>> So, getReturnedClass().getClassLoader() is not the answer here. >>> There is the only answer unfortunately. Really you'd want the Class of >>> the class implementing Serializable, but given how Hibernate's "type >>> system" works currently, that's not an option. >> >> If it's not an option, why don't u throw an error or exception? >> >>> >>>> >>>> Steve, from a chat earlier you indicated that you're not happy passing >>>> Thread.currentThread().getContextClassLoader() but I don't understand >>>> what issue do you have with this. >>> The main issue is that this relies on: >>> 1) when the call is made >>> 2) the classloader layout of the environment in which the call occurs. >>> OSGI comes to mind in which case there is actually no tccl afaik. >>> >>>> Finally, it might be worth understanding what, apart from query cache, >>>> is Hibernate's SerializationHelper used for. If it's only for caching, >>>> you could maybe delegate serialization work to the cache providers? >>> Thats really a simple matter of a usage search in your IDE. >>> >>> -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Reelase for
The cutoff for getting external libs integrated into the AS trunk for M2 is Jan 31. I'd consider holding it open a bit longer for Hibernate (at most a week) if it meant getting feature complete and stable JPA2 impl. I wouldn't want to hold it open though to go from 75% complete to 85% or some such. The AS needs to enforce time-box discipline on itself. :) If you've got a substantial set of work completed, I'm all in favor of getting a new beta integrated ASAP. Better to surface any issues now than at the last minute. Also, it seems to me the integration testsuite in the AS for JPA2 needs beefing up; that work can start as soon as an impl with the features under test is integrated. If you think you're going to go past the Jan 31 deadline, I very much want another beta integrated soon. Going past Jan 31 cuts into the short (two week) window between component integration cutoff and turning over M2 to QE. That adds risk, so let's reduce that risk by seeing where we stand now. Note though that the latest Microcontainer release will be getting integrated into AS trunk in the next few days. That will likely disturb things for a few days. If the point of another beta is to test it in AS, holding off a few days is IMO wise. On 01/08/2010 08:39 AM, Scott Marlow wrote: > Steve, > > Is this expected to be the final build for AS M2? My vote is to build > 3.5.0-Beta-3 soon and another (more JPA-2 feature complete) build in > February (for inclusion in AS M2). I don't care what we label the > February build (3.5.0-Beta-4 or 3.5 final). > > An alternative would be to hold off on building 3.5.0-Beta-3 for a few > weeks (so we can get more JPA-2 features completed for AS M2). > > > Scott > > On Thu, 2010-01-07 at 16:13 -0600, Steve Ebersole wrote: >> I went ahead and set up this next release in JIRA (3.5.0-Beta-3) and >> moved all unresolved issues to the 3.5 working release. If there is >> anything you need in 3.5.0-Beta-3 that is not there speak up now (by >> scheduling the corresponding JIRA issue) or forever hold your piece :) >> >> >> On Thu, 2010-01-07 at 09:14 -0600, Steve Ebersole wrote: >>> Sure, let's do one at the beginning of next week. >>> >>> On Wed, 2010-01-06 at 18:11 +0100, Emmanuel Bernard wrote: >>>> Steve, >>>> Do you think there is enough material / bug fix to cut another beta >>>> for inclusion in AS 6 M2? >>>> Something like a 2 weeks target. >>>> >>>> >>>> On my side that would make sense to push the discrete but new >>>> mapping / bug fixes out for trial. It also helps Hibernate Search >>>> development (on Core snapshot ATM). >>>> >>>> >>>> Emmanuel >>>> >>>> Begin forwarded message: >>>> >>>>> From: Brian Stansberry >>>>> >>>>> Date: 6 janvier 2010 17:38:37 HNEC >>>>> >>>>> To: jboss-developm...@lists.jboss.org >>>>> >>>>> Subject: Re: [jboss-dev] Further profling: Where should I focus? >>>>> >>>>> Reply-To: "JBoss.org development list" >>>>> >>>>> >>>>>> >>>>>> >>>>>> Any ETA on VFS3 being done and integrated with AS 6? >>>>>> >>>>> >>>>> My guesstimate is very early in the M3 cycle (i.e. as soon as we >>>>> open >>>>> trunk to commits after M2). So mid-February. >>>>> >>>>> It's tempting to try for M2, but there's only 3.5 weeks left before >>>>> component integration freeze, this is a big disruptive change and >>>>> there >>>>> are a couple issues to resolve: >>>>> >>>>> 1) Detecting modifications of exploded deployments: >>>>> http://community.jboss.org/thread/146098 >>>>> >>>>> 2) This caching discussion, which IMHO should continue. It's legit >>>>> to >>>>> think again about what the intended use cases are for VFS and see if >>>>> its >>>>> API can be adjusted to more effectively handle those use cases. >>>>> >>>>> The MC team is going to be putting out a 2.2 alpha release soon; >>>>> while >>>>> that's being integrated in the AS and issues resolved over the next >>>>> week >>>>> it makes little sense to try and start pushing in VFS3. So let's >>>>> use >>>>> that time to resolve the modification detection issue and discuss a >>>>> bit >>>>> more about caching. By the end of next week we should have a >>>>> clearer >>>>> picture as to whether trying for M2 is feasible. >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Lead, AS Clustering >>>>> JBoss by Red Hat >>>>> ___ >>>>> jboss-development mailing list >>>>> jboss-developm...@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>> >>>> > > -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trunk failing because of infinispan tests
I'm forwarding this to the infinispan-dev list so the Infinispan guys can fix it. Pinging them on IM as well. On 12/01/2009 05:55 AM, Juraci Paixao Krohling wrote: > Guys, > > As I know there are some Infinispan guys on this list, I'm sending it > here. It seems that Infinispan maven repo used to contain some > "-tests.jar" artifacts, but they weren't published on Nov 30, causing > Hibernate trunk build to fail (look at cache-infinispan/pom.xml). > Question is: should we remove the dependency from > cache-infinispan/pom.xml or will Infinispan guys resume publishing the > "-tests.jar" into their repository? > > Path to dependency: > 1) org.hibernate:hibernate-infinispan:jar:3.5.0-SNAPSHOT > 2) org.infinispan:infinispan-core:test-jar:tests:4.0.0-SNAPSHOT > > It tried to download this: > > http://snapshots.jboss.org/maven2/org/infinispan/infinispan-core/4.0.0-SNAPSHOT/infinispan-core-4.0.0-20091130.165452-15-tests.jar > > - Juca. > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Exposing transient/mortality information externally
Be cautious about exposing cache contents (even just keys) via JMX. If you do, make it something that people can turn off, without turning off the basic JMX interface. Reason is the same as in recent discussions about providing access to the cache itself via JMX. People who deploy a JMX-enabled cache are not necessarily expecting that any code that can access the MBean server can also inspect cache contents. For example, a simple session id string is a likely key, and session ids are essentially a security token that shouldn't be exposed willy-nilly. In general, for the Hibernate 2LC use case, IMHO it's better if the Hibernate statistics API is improved, rather than having people access the cache directly. How the data is stored in the cache should be an internal implementation detail that can be changed when needed. That's part of why your addition of eviction configuration to Hibernate Configuration properties was so nice. All that said, if information like > [Person#1:[created:123456,lifespan:12,maxIdle:6,lasUsed:13456], > Person#2:[created:234567,lifespan:12,maxIdle:6,lasUsed:24567], > ...] is readily available internally, having a mechanism for authorized users to get at it sounds pretty cool. :-) On 11/26/2009 03:16 AM, Galder Zamarreno wrote: > Hi, > > Re: > http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267469#4267469 > > I think Brian has a good point here. We don't expose any internal > information wrt each cache entry's expiry/eviction values. Brian has a > good point that this could guide him in finding out which entries have > been last been used, how long they've been in memory and how it could > tweak expiration/eviction accordingly. > > If we don't do anything, I think we run the risk of people being forced > to get hold of the container, looping through it and getting information > that they need from inspecting internal classes. > > So, I'd suggest that we add a JMX method to CacheDelegate called > something like: > > Map> getTransientAndMortalityInformation(). > > (I'm open to suggestions to other names. This is the 1st thing that came > to my mind) > > This would return a Map where the key is the toString form of the cache > key and the value part is a map where individual transient/mortal > properties are returned. I.e. > > > > We could event add calculated properties such as 'age' which is current > - created. This would vary with each call obviously. > > As indicated in the forum entry, at least based on this use case, I > don't see an immediate need to query this type of information given a > key, although could be potentially useful for other use cases. The > reason this would not help much right now is because it is Hibernate > that creates the keys of 2nd level cache (i.e. CacheKey) and these are > nor meant to be recreated externally, so it'd be hard for external apps > to get something out of the Infinispan cache directly without going > through the Hibernate integration layer. > > My suggested JMX method could allow for individual transient/mortality > information to be queried by tools, or other client jmx code. Maybe some > tools could use that to create a table or something like that which > could be ordered based on a column? i.e. age. Also, tools or client jmx > code could convert those longs into whatever they want: seconds, > minutes...etc > > The reason I think JMX is a good candidate here is this is inherently > monitoring information and it allows us to expose internal information > via primitives without having to expose internal classes. > > Thoughts? > > Cheers, -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate 3.4 + JBoss Cache 2.5 question on stackoverflow
FYI, this has been fixed in JBoss trunk. On 10/28/2009 09:25 PM, Brian Stansberry wrote: > It's semi-maintained, but TBH it seems rather convoluted and thus fragile. > > I've opened https://jira.jboss.org/jira/browse/JBAS-7411 for this and > will post a link to that on the stackoverflow thread. > > There's a deployer that parses a hibernate.cfg.xml into a metadata > object, which includes the set of configuration properties stored as a > key/value pairs. But the property names you use have to map to > properties on the org.jboss.hibernate.jmx.Hibernate class, because the > deployer uses JBoss MC property injection to populate the > o.j.h.jmx.Hibernate object. So you can't use the regular Hibernate > property names, which include '.' and such. Plus it breaks when > Hibernate adds a new property, a la what this user is seeing. > > In its start() method the org.jboss.hibernate.jmx.Hibernate class then > builds a Hibernate Configuration object, by mapping it's property values > back to the standard Hibernate configuration property names. > > More sensible IMHO is to inject into the o.j.h.jmx.Hibernate object the > original set of parsed key/value pairs via a new > setProperties(Set) method. The start() method would > then build the Configuration from that set of properties. This would > allow any valid Hibernate property to be used and would remove the need > to use AS-specific property names. The Hibernate MBean interface would > then just expose whatever properties we've chosen to map. > > We should of course also support the legacy AS-specific property names. > > On Oct 27, 2009, at 12:22 AM, Galder Zamarreno wrote: > >> Hi guys, >> >> Re: >> http://stackoverflow.com/questions/1443192/jbosscache-as-a-second-level-cache-for-hibernate-in-jboss-5/ >> >> >> AFAIK, the hibernate MBean is no longer maintained, hence why the new >> properties such as hibernate.cache.region.jbc2.cfg.entity are not mapped >> to Hibernate MBean attributes. Am I correct? Would someone from the >> Hibernate team care to provide an answer? >> >> Cheers, >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate 3.4 + JBoss Cache 2.5 question on stackoverflow
It's semi-maintained, but TBH it seems rather convoluted and thus fragile. I've opened https://jira.jboss.org/jira/browse/JBAS-7411 for this and will post a link to that on the stackoverflow thread. There's a deployer that parses a hibernate.cfg.xml into a metadata object, which includes the set of configuration properties stored as a key/value pairs. But the property names you use have to map to properties on the org.jboss.hibernate.jmx.Hibernate class, because the deployer uses JBoss MC property injection to populate the o.j.h.jmx.Hibernate object. So you can't use the regular Hibernate property names, which include '.' and such. Plus it breaks when Hibernate adds a new property, a la what this user is seeing. In its start() method the org.jboss.hibernate.jmx.Hibernate class then builds a Hibernate Configuration object, by mapping it's property values back to the standard Hibernate configuration property names. More sensible IMHO is to inject into the o.j.h.jmx.Hibernate object the original set of parsed key/value pairs via a new setProperties (Set) method. The start() method would then build the Configuration from that set of properties. This would allow any valid Hibernate property to be used and would remove the need to use AS-specific property names. The Hibernate MBean interface would then just expose whatever properties we've chosen to map. We should of course also support the legacy AS-specific property names. On Oct 27, 2009, at 12:22 AM, Galder Zamarreno wrote: > Hi guys, > > Re: > http://stackoverflow.com/questions/1443192/jbosscache-as-a-second-level-cache-for-hibernate-in-jboss-5/ > > AFAIK, the hibernate MBean is no longer maintained, hence why the new > properties such as hibernate.cache.region.jbc2.cfg.entity are not > mapped > to Hibernate MBean attributes. Am I correct? Would someone from the > Hibernate team care to provide an answer? > > Cheers, > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] Query cache region implementation, getting transaction manager?
The TM should be available to you. In the JBC integration, it's actually the integration that injects the TM into JBC! See start() in https://svn.jboss.org/repos/hibernate/core/trunk/cache-jbosscache/src/main/java/org/hibernate/cache/jbc/builder/MultiplexingCacheInstanceManager.java On 08/17/2009 07:09 AM, Galder Zamarreno wrote: > Hmmm, potentially from Hibernate. Adding hibernate-dev to the > discussion. What's the correct way to get hold of the transaction > manager in a Hibernate env? > > org.hibernate.transaction.TransactionManagerLookupFactory.getTransactionManager(Properties > props) > > On 08/17/2009 02:00 PM, Manik Surtani wrote: >> Why do you need to get the TM from Infinispan? Surely there would be >> other ways to get this, either from Hibernate or from JNDI? >> >> On 17 Aug 2009, at 12:38, Galder Zamarreno wrote: >> >>> Hi, >>> >>> I'm currently working on the query cache region and calling get() on >>> query cache region should suspend current transaction. With JBC, we used >>> to call the following to get the transaction manager: >>> >>> cache.getConfiguration().getRuntimeConfig().getTransactionManager(); >>> >>> However, this API is not available in Infinispan. What should be the >>> correct way to get the transaction manager? >>> TestingUtil.geTransactionManager() includes a method to do so but I >>> don't think such method should be used for anything other than testing. >>> >>> Thoughts? >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> ___ >>> infinispan-dev mailing list >>> infinispan-...@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> ma...@jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> > -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 08/13/2009 06:27 AM, Galder Zamarreno wrote: > Hi Brian, > > Of my original email, there's a section that I don't think has been > answered yet > > On 08/04/2009 10:37 AM, Galder Zamarreno wrote: >> Finally, a question to the list, specially for Brian/Steve who worked on >> the JBC2/3 integration layer: >> >> - Do we need a similar timestamp region local cache implementation for >> an ISPN based cache provider? >> >> Cheers, > > This question focuses on the TimestampsRegionImpl (and potentially > ClusteredConcurrentTimestampsRegionImpl) work done for JBC 2.x/3.x > integration layer. Is there a need for a similar region implementation > for Infinispan? I'm not sure I fully understand the need for > TimestampsRegionImpl to manage this local cache. > Timestamps caching has different semantics than the other types, hence the different region impl. I don't know any reason why that wouldn't be the case with Infinispan. It's not a "local cache"? It's replicated. > Talking about timestamps, I assume that no evictions should ever happen > for the timestamps cache and this is something that could be validated > on startup, that eviction strategy is NONE. > +1. > Cheers, -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Galder Zamarreno wrote: > > > On 08/05/2009 04:04 PM, Brian Stansberry wrote: >> Galder Zamarreno wrote: >>> > >>> >> >> Sounds like this has diverged quite a bit from the JBC integration then. >> In your initial message you were discussing names: >> >> hibernate.cache.region.ispn4.cfg.entity >> hibernate.cache.region.ispn4.cfg.collection >> hibernate.cache.region.ispn4.cfg.query >> hibernate.cache.region.ispn4.cfg.timestamps >> >> What were those to be used for? With JBC they identify the name of a >> cache configuration, which is used to obtain an appropriately configured >> org.jboss.cache.Cache from the JBC CacheManager. My assumption on this >> thread was the same basic approach would be used with Infinispan. The >> "region name" that Hibernate passes is not meant to be the name of the >> cache configuration. It could be a unique identifier for the cache >> that's created using that configuration, but it's not the name of the >> configuration. > > Those names are not yet in use. They're just initial suggestions I had > in mind to map JBC2/3 cache integration to ISPN. Shortly after I > realised that actually, for each entity/collection, a cache was being > created. > >> >> If you follow that approach, you use the above properties to establish >> defaults for each of the 4 data types. You then use the techniques you >> discuss below to override those defaults if people need specialized >> configs for certain entities. > > And I suppose that using those 4 properties follows the same kind of > default pattern as previous cache integration layer which is a good thing. > Cool. Being able to configure different caches per entity type will be kinda nice. Semi-tangent: in general I really dislike if people have to configure JBC/Infinispan to get standard behaviors (e.g. eviction). Much better if people can use the standard configuration mechanism of whatever service is using JBC/Infinispan, and only touch JBC/Infinispan configs for exotic stuff. So, for example, web session passivation is configured via jboss-web.xml, not via a JBC eviction region. If the properties needed to configure 2nd Level Cache eviction could be reduced to 2 or 3, being able to express them via the SessionFactory config would be nice, e.g. hibernate.cache.infinispan.Users.max_age=5000 Perhaps just support LRU that way; if people want exotic stuff beyond LRU they have to go to the Infinispan config. Moving beyond that, in the AS, w/ the AS impl of the JBC CacheManager I was going to add capability to take a standard named config as a base (e.g. "standard-session-cache") and then modify it to match application-specified overrides (e.g. true) I'd then generate a name for that config, and register it back with the CacheManager for use, then use it to create a cache. I'd like to do the same kind of thing with the Infinispan replacement of JBC's CacheManager. Same kind of thing could be done in the Hibernate use case for eviction. -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Galder Zamarreno wrote: > > > On 08/04/2009 06:40 PM, Brian Stansberry wrote: >> Galder Zamarreno wrote: >>> >>> >>> On 08/04/2009 06:23 PM, Brian Stansberry wrote: > > > >>>> >>>> Also, unless there's a really good reason not too, let's try to keep >>>> things logically the same between the Infinispan and JBC integrations. >>>> Makes maintenance much easier. >>> >>> Assuming that >>> org.hibernate.test.cache.infinispan.functional.Item.items is a >>> Collection belonging to >>> org.hibernate.test.cache.infinispan.functional.Item, do you agree on >>> keeping each in a separate cache? >>> >> >> Yes. With JBC they are separate Regions. We need the ability to scope >> things like clear commands to the data hibernate is working with, and an >> entity and its associated collections are separate things to hibernate. > > Ok, so they need to be kept in separate cache instances then. Thx. > > > >>>>> >>>>>> I suppose that would depend on the need for different eviction >>>>>> characteristics for different entity types. So from that perspective >>>>>> (the ability to use) a different cache per entity is useful. >>>>>> >>>>>> E.g., >>>>>> >>>>>> NoEvictionCache for [CountryList] >>>>>> NoEvictionCache for [SomeOtherDropDown] >>>>>> AggressivelyEvictedLRUCache for [Users] >>>>>> AggressivelyEvictedLRUCache for [Orders] >>>>>> LargeCapacityFIFOCache for [ProductsCatalog] >>>>>> >>>>>> etc. may well prove useful. Brian/Steve - care to chime in? >>> >>> No, we haven't lost it at all. You can define a cache with specific >>> eviction settings and give it as name the FQCN of the entity and >>> that's done. >>> >> >> How is this configured by the end user? I mean the mapping from the >> entity type to the cache config name. Is something like what I described >> below implemented already? > > No, that's not there yet. At the moment, we simply take the region name > that we're passed (this defaults to entity type FQCN) and we look up a > cache from cache manager with that name. > Sounds like this has diverged quite a bit from the JBC integration then. In your initial message you were discussing names: hibernate.cache.region.ispn4.cfg.entity hibernate.cache.region.ispn4.cfg.collection hibernate.cache.region.ispn4.cfg.query hibernate.cache.region.ispn4.cfg.timestamps What were those to be used for? With JBC they identify the name of a cache configuration, which is used to obtain an appropriately configured org.jboss.cache.Cache from the JBC CacheManager. My assumption on this thread was the same basic approach would be used with Infinispan. The "region name" that Hibernate passes is not meant to be the name of the cache configuration. It could be a unique identifier for the cache that's created using that configuration, but it's not the name of the configuration. If you follow that approach, you use the above properties to establish defaults for each of the 4 data types. You then use the techniques you discuss below to override those defaults if people need specialized configs for certain entities. > Having had a thought overnight to this, I do see the point of having > that mapping though, otherwise if you have 10 entities which cache > settings A and 10 entities with cache settings B, we'd be needing to > implement 20 cache definitions. See below for a further discussion on > your suggested mapping. > >> >>> The problem though is that for each Collection this entity has, you'd >>> need a separate cache instance since at the moment, an entity's >>> collection is stored in a separate cache. >>> >>> So, if Person has several Address instances, Person will be one cache >>> instance and his/hers addresses would be stored in a different cache >>> instance. >>> >> >> True. Although this is only an issue if you wanted separate eviction. >> Hibernate allows you to specify a region name for any cachable item >> (except timestamps). The use of FQCN is just a default for people who >> don't want to configure things. >> >>>>> >>>>> hehe, I kinda just somewhat did on another branch of the thread. W/ >>>>> JBC, different eviction per entity type could be configured via the >>>>> JBC config, using eviction regions. See
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Galder Zamarreno wrote: > > > On 08/04/2009 06:23 PM, Brian Stansberry wrote: >> Got distracted and hit send early last time... >> >> Brian Stansberry wrote: >>> Manik Surtani wrote: >>>> >>>> On 4 Aug 2009, at 14:02, Galder Zamarreno wrote: >>>> >>>>>> >>>>>> s/region.ispn4/infinispan >>>>> >>>>> Ok. >>>>> >>>>> One thing here though. Chris's original solution works in such way >>>>> that for each entity/collection, a new cache is retrieved from the >>>>> cache manager using the region name, so for this example 3 caches >>>>> would be created: >>>>> >>>>> Cache1 for >>>>> [org.hibernate.test.cache.infinispan.functional.VersionedItem] >>>>> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item] >>>>> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item.items] >>>>> >>>>> Can we confirm this is the intented way? In >>>>> https://jira.jboss.org/jira/browse/ISPN-6 the following is mentioned: >>>>> >>>>> "Use a separate named cache per entity. This cache would hold entity >>>>> instances as well as collections pertaining to that entity." >>>>> >> >> In the JBC2 integration, the JBC Region is pretty important, beyond >> eviction. There are things like clear operations that are scoped to the >> Region (e.g. to support invalidating all entities of a given type out of >> the cache). The Infinispan integration will have the same use cases, and >> AIUI a cache is the semi-analogue to a JBC Region, so I think you need a >> cache per entity type. > > + 1 > >> >> Also, unless there's a really good reason not too, let's try to keep >> things logically the same between the Infinispan and JBC integrations. >> Makes maintenance much easier. > > Assuming that org.hibernate.test.cache.infinispan.functional.Item.items > is a Collection belonging to > org.hibernate.test.cache.infinispan.functional.Item, do you agree on > keeping each in a separate cache? > Yes. With JBC they are separate Regions. We need the ability to scope things like clear commands to the data hibernate is working with, and an entity and its associated collections are separate things to hibernate. >> >>>>> So, if that is followed and we bear in mind the above example, there >>>>> should only be 2 cache instances created rather than the current 3. >>>>> >>>>> What is clear is that there's no need for >>>>> hibernate.cache.infinispan.cfg.entity or >>>>> hibernate.cache.region.ispn4.cfg.collection. Simply stick the >>>>> default cache configuration for entity/collections in the default >>>>> section of configuration. >>>>> >>> >>> Yeah, I've never found a good use case for using different configs for >>> the two. Perhaps eviction >>> >>>>> I don't we need hibernate.cache.infinispan.cfg.query and >>>>> hibernate.cache.infinispan.cfg.timestamps either since we can simply >>>>> name the caches with the corresponding region names >>>>> (org.hibernate.cache.UpdateTimestampsCache]and >>>>> org.hibernate.cache.StandardQueryCache) and that's it. >>>> >>> >>> The hibernate.cache.infinispan.cfg.query and >>> hibernate.cache.infinispan.cfg.timestamps properties aren't used to >>> name the caches. They specify what config to use. >>> >>>> I suppose that would depend on the need for different eviction >>>> characteristics for different entity types. So from that perspective >>>> (the ability to use) a different cache per entity is useful. >>>> >>>> E.g., >>>> >>>> NoEvictionCache for [CountryList] >>>> NoEvictionCache for [SomeOtherDropDown] >>>> AggressivelyEvictedLRUCache for [Users] >>>> AggressivelyEvictedLRUCache for [Orders] >>>> LargeCapacityFIFOCache for [ProductsCatalog] >>>> >>>> etc. may well prove useful. Brian/Steve - care to chime in? > > No, we haven't lost it at all. You can define a cache with specific > eviction settings and give it as name the FQCN of the entity and that's > done. > How is this configured by the end user? I mean the mapping from the entity type to the cache config name. Is something like w
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Got distracted and hit send early last time... Brian Stansberry wrote: > Manik Surtani wrote: >> >> On 4 Aug 2009, at 14:02, Galder Zamarreno wrote: >> >>>> >>>> s/region.ispn4/infinispan >>> >>> Ok. >>> >>> One thing here though. Chris's original solution works in such way >>> that for each entity/collection, a new cache is retrieved from the >>> cache manager using the region name, so for this example 3 caches >>> would be created: >>> >>> Cache1 for >>> [org.hibernate.test.cache.infinispan.functional.VersionedItem] >>> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item] >>> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item.items] >>> >>> Can we confirm this is the intented way? In >>> https://jira.jboss.org/jira/browse/ISPN-6 the following is mentioned: >>> >>> "Use a separate named cache per entity. This cache would hold entity >>> instances as well as collections pertaining to that entity." >>> In the JBC2 integration, the JBC Region is pretty important, beyond eviction. There are things like clear operations that are scoped to the Region (e.g. to support invalidating all entities of a given type out of the cache). The Infinispan integration will have the same use cases, and AIUI a cache is the semi-analogue to a JBC Region, so I think you need a cache per entity type. Also, unless there's a really good reason not too, let's try to keep things logically the same between the Infinispan and JBC integrations. Makes maintenance much easier. >>> So, if that is followed and we bear in mind the above example, there >>> should only be 2 cache instances created rather than the current 3. >>> >>> What is clear is that there's no need for >>> hibernate.cache.infinispan.cfg.entity or >>> hibernate.cache.region.ispn4.cfg.collection. Simply stick the default >>> cache configuration for entity/collections in the default section of >>> configuration. >>> > > Yeah, I've never found a good use case for using different configs for > the two. Perhaps eviction > >>> I don't we need hibernate.cache.infinispan.cfg.query and >>> hibernate.cache.infinispan.cfg.timestamps either since we can simply >>> name the caches with the corresponding region names >>> (org.hibernate.cache.UpdateTimestampsCache]and >>> org.hibernate.cache.StandardQueryCache) and that's it. >> > > The hibernate.cache.infinispan.cfg.query and > hibernate.cache.infinispan.cfg.timestamps properties aren't used to name > the caches. They specify what config to use. > >> I suppose that would depend on the need for different eviction >> characteristics for different entity types. So from that perspective >> (the ability to use) a different cache per entity is useful. >> >> E.g., >> >> NoEvictionCache for [CountryList] >> NoEvictionCache for [SomeOtherDropDown] >> AggressivelyEvictedLRUCache for [Users] >> AggressivelyEvictedLRUCache for [Orders] >> LargeCapacityFIFOCache for [ProductsCatalog] >> >> etc. may well prove useful. >> Brian/Steve - care to chime in? > > hehe, I kinda just somewhat did on another branch of the thread. W/ JBC, > different eviction per entity type could be configured via the JBC > config, using eviction regions. Seems we've lost that, unless > SessionFactory properties are added that tell the RegionFactory what > Infinispan config to use on a more fine-grained basis than "entity", > "collection", "query", "timestamp". This could perhaps be done by using > "entity", "query" as default values and allowing replacement/extension > to override the default for a particular region name. > > hibernate.cache.infinispan.CountryList.cfg=NoEvictionCache > > The ugly bit is that works if people configure a region name for their > entities, rather than using the default fully qualified class name. I > suppose the fully qualified class name could work as well, just a bit > more parsing. > >> >> Cheers >> -- >> Manik Surtani >> ma...@jboss.org <mailto:ma...@jboss.org> >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> > > -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Manik Surtani wrote: > > On 4 Aug 2009, at 14:02, Galder Zamarreno wrote: > >>> >>> s/region.ispn4/infinispan >> >> Ok. >> >> One thing here though. Chris's original solution works in such way >> that for each entity/collection, a new cache is retrieved from the >> cache manager using the region name, so for this example 3 caches >> would be created: >> >> Cache1 for [org.hibernate.test.cache.infinispan.functional.VersionedItem] >> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item] >> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item.items] >> >> Can we confirm this is the intented way? >> In https://jira.jboss.org/jira/browse/ISPN-6 the following is mentioned: >> >> "Use a separate named cache per entity. This cache would hold entity >> instances as well as collections pertaining to that entity." >> >> So, if that is followed and we bear in mind the above example, there >> should only be 2 cache instances created rather than the current 3. >> >> What is clear is that there's no need for >> hibernate.cache.infinispan.cfg.entity or >> hibernate.cache.region.ispn4.cfg.collection. Simply stick the default >> cache configuration for entity/collections in the default section of >> configuration. >> Yeah, I've never found a good use case for using different configs for the two. Perhaps eviction >> I don't we need hibernate.cache.infinispan.cfg.query and >> hibernate.cache.infinispan.cfg.timestamps either since we can simply >> name the caches with the corresponding region names >> (org.hibernate.cache.UpdateTimestampsCache]and >> org.hibernate.cache.StandardQueryCache) and that's it. > The hibernate.cache.infinispan.cfg.query and hibernate.cache.infinispan.cfg.timestamps properties aren't used to name the caches. They specify what config to use. > I suppose that would depend on the need for different eviction > characteristics for different entity types. So from that perspective > (the ability to use) a different cache per entity is useful. > > E.g., > > NoEvictionCache for [CountryList] > NoEvictionCache for [SomeOtherDropDown] > AggressivelyEvictedLRUCache for [Users] > AggressivelyEvictedLRUCache for [Orders] > LargeCapacityFIFOCache for [ProductsCatalog] > > etc. may well prove useful. > > Brian/Steve - care to chime in? hehe, I kinda just somewhat did on another branch of the thread. W/ JBC, different eviction per entity type could be configured via the JBC config, using eviction regions. Seems we've lost that, unless SessionFactory properties are added that tell the RegionFactory what Infinispan config to use on a more fine-grained basis than "entity", "collection", "query", "timestamp". This could perhaps be done by using "entity", "query" as default values and allowing replacement/extension to override the default for a particular region name. hibernate.cache.infinispan.CountryList.cfg=NoEvictionCache The ugly bit is that works if people configure a region name for their entities, rather than using the default fully qualified class name. I suppose the fully qualified class name could work as well, just a bit more parsing. > > Cheers > -- > Manik Surtani > ma...@jboss.org <mailto:ma...@jboss.org> > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Galder Zamarreno wrote: > Hi, > > Re: https://jira.jboss.org/jira/browse/ISPN-6 > > Source code for this is currently located in an Infinispan branch in the > Hibernate SVN repo: > > https://svn.jboss.org/repos/hibernate/core/branches/INFINISPAN/ > http://anonsvn.jboss.org/repos/hibernate/core/branches/INFINISPAN/ > > I've picked this JIRA from Chris Bredesen. I'm waiting to get an answer > to an email I sent him yesterday but in the mean time, here's a list of > TODOs: > > 1. Current Infinispan region factory needs to point to a config with > named caches. Suggested property name: hibernate.cache.region.ispn4.configs > > 2. Need a equivalent version of this region factory where cache manager > is retrieved from JNDI. Suggsted property name: > hibernate.cache.region.ispn4.manager > > 3. Configuration properties for named cache names. Suggested property > names: > hibernate.cache.region.ispn4.cfg.entity > hibernate.cache.region.ispn4.cfg.collection > hibernate.cache.region.ispn4.cfg.query > hibernate.cache.region.ispn4.cfg.timestamps > > 4. Resolve TransactionalAccess, ReadOnlyAccess and BaseRegion TODOs. > > 5. Enhance query results region so that query changes are not propagated > if invalidation is used and add query.localonly equivalent property. > Suggested name: hibernate.cache.region.ispn4.query.localonly > > 6. Add more unit tests! > > 7. Document in wiki. > > Some notes I've made while investigating this: > > - Whereas with JBC2/3, we had the possibility of a shared cache for all > types (entities, collections, query,...etc) and a multiplexed version > where each type had a specific cache, in Infinispan, it only makes the > latter. Amongst other reasons because we don't have eviction regions any > more and so we can't exclude the timestamp modification region as we did > in JBC2/3. Overall, having a single option is a good thing from a > configuration and usability perspective! Remember how complex eviction > region definition could get for entities... > Is this basically a configuration issue? I.e. the eviction would have to be configured via Hibernate SessionFactory properties, since the Infinispan config file can't express it? That's unfortunate, as it means different entity types can't have different eviction behavior. The timestamps could be handled programatically; the Hib/Ispn integration knows it's dealing with timestamps. All that said, I have no problem with eliminating the possibility of a shared cache. There is no legacy usage to support like there was with JBC2. And if people want a shared cache, we can revisit. > Finally, a question to the list, specially for Brian/Steve who worked on > the JBC2/3 integration layer: > > - Do we need a similar timestamp region local cache implementation for > an ISPN based cache provider? > Sorry, I don't understand the question. > Cheers, -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [jbosscache-dev] Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core
Elias Ross was kind enough to notify me privately that the difference in method signature isn't the generics (which of course don't matter at runtime), it's the change in return type from CacheFactory to DefaultCacheFactory. DOH! Maxim: if the only remaining answer is impossible, don't decide the impossible is the answer. Look again and see the blindingly obvious possible answer. :-) Brian Stansberry wrote: Sorry, Manik, tests were failing w/ NoSuchMethodError and I saw your recent change in hibernate trunk to remove use of DefaultCacheFactory.getInstance() and assumed the method was gone. My bad :-( Perhaps problem is loss of generics info in the class file? 2.1.0.GA: public static CacheFactory getInstance() 3.0.0.CR1: public static DefaultCacheFactory getInstance() Failure I see is: java.lang.NoSuchMethodError: org.jboss.cache.DefaultCacheFactory.getInstance()Lorg/jboss/cache/CacheFactory; at org.hibernate.cache.jbc2.builder.SharedCacheInstanceManager.createSharedCache(SharedCacheInstanceManager.java:193) I don't remember exactly how I tested this yesterday, but messing with it today, I can reproduce by: 1) revert pom in my checkout of the 3.3.1 tag so it uses JBC 2.1.0.GA 2) revert any compiled classes back to the original 3.3.1 mvn -Dmaven.test.skip.exec=true clean install 3) change the pom so it uses JBC 3.3.0.CR1 and JGroups 2.6.5 4) run the testsuite mvn -Ptest test Tests run: 225, Failures: 0, Errors: 21, Skipped: 0 5) force a new compile and then retest: mvn -Ptest clean test ... Tests run: 225, Failures: 0, Errors: 0, Skipped: 0 Problem is people using a 3.3.1 binary don't get to recompile. ;) Manik Surtani wrote: Weird, getInstance() was removed in early ALPHAs, and was replaced again pretty quickly - in 3.0.0.BETA1, even. http://fisheye.jboss.org/browse/JBossCache/core/tags/3.0.0.BETA1/src/main/java/org/jboss/cache/DefaultCacheFactory.java?r=6676 2008/10/18 Jason T. Greene <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> Brian Stansberry wrote: Steve Ebersole wrote: so JBC 3 needs this change anyway? Yes, if it wants to go in, say, JBoss AS 5.2. Which I'm quite sure the JBC team wants, since they made a bunch of other more significant changes to ensure compatibility. This one's real trivial. at which point it would be a total drop-in replacement? Yes. I just did a diff between head of trunk (which passes 100% w/ JBC 3.0.0.CR1 plugged in) and the hibernate-3.3.1.GA <http://hibernate-3.3.1.GA> tag and the only differences are two places where the missing DefaultCacheFactory.getInstance() call was replaced. I fixed this compatibility problem awhile ago, but it could have been after CR1 was tagged. -- Jason T. Greene JBoss, a division of Red Hat ___ jbosscache-dev mailing list [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> https://lists.jboss.org/mailman/listinfo/jbosscache-dev -- Brian Stansberry Lead, AS Clustering 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
Re: [jbosscache-dev] Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core
Sorry, Manik, tests were failing w/ NoSuchMethodError and I saw your recent change in hibernate trunk to remove use of DefaultCacheFactory.getInstance() and assumed the method was gone. My bad :-( Perhaps problem is loss of generics info in the class file? 2.1.0.GA: public static CacheFactory getInstance() 3.0.0.CR1: public static DefaultCacheFactory getInstance() Failure I see is: java.lang.NoSuchMethodError: org.jboss.cache.DefaultCacheFactory.getInstance()Lorg/jboss/cache/CacheFactory; at org.hibernate.cache.jbc2.builder.SharedCacheInstanceManager.createSharedCache(SharedCacheInstanceManager.java:193) I don't remember exactly how I tested this yesterday, but messing with it today, I can reproduce by: 1) revert pom in my checkout of the 3.3.1 tag so it uses JBC 2.1.0.GA 2) revert any compiled classes back to the original 3.3.1 mvn -Dmaven.test.skip.exec=true clean install 3) change the pom so it uses JBC 3.3.0.CR1 and JGroups 2.6.5 4) run the testsuite mvn -Ptest test Tests run: 225, Failures: 0, Errors: 21, Skipped: 0 5) force a new compile and then retest: mvn -Ptest clean test ... Tests run: 225, Failures: 0, Errors: 0, Skipped: 0 Problem is people using a 3.3.1 binary don't get to recompile. ;) Manik Surtani wrote: Weird, getInstance() was removed in early ALPHAs, and was replaced again pretty quickly - in 3.0.0.BETA1, even. http://fisheye.jboss.org/browse/JBossCache/core/tags/3.0.0.BETA1/src/main/java/org/jboss/cache/DefaultCacheFactory.java?r=6676 2008/10/18 Jason T. Greene <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> Brian Stansberry wrote: Steve Ebersole wrote: so JBC 3 needs this change anyway? Yes, if it wants to go in, say, JBoss AS 5.2. Which I'm quite sure the JBC team wants, since they made a bunch of other more significant changes to ensure compatibility. This one's real trivial. at which point it would be a total drop-in replacement? Yes. I just did a diff between head of trunk (which passes 100% w/ JBC 3.0.0.CR1 plugged in) and the hibernate-3.3.1.GA <http://hibernate-3.3.1.GA> tag and the only differences are two places where the missing DefaultCacheFactory.getInstance() call was replaced. I fixed this compatibility problem awhile ago, but it could have been after CR1 was tagged. -- Jason T. Greene JBoss, a division of Red Hat ___ jbosscache-dev mailing list [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> https://lists.jboss.org/mailman/listinfo/jbosscache-dev -- Brian Stansberry Lead, AS Clustering 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
Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core
Steve Ebersole wrote: so JBC 3 needs this change anyway? Yes, if it wants to go in, say, JBoss AS 5.2. Which I'm quite sure the JBC team wants, since they made a bunch of other more significant changes to ensure compatibility. This one's real trivial. at which point it would be a total drop-in replacement? Yes. I just did a diff between head of trunk (which passes 100% w/ JBC 3.0.0.CR1 plugged in) and the hibernate-3.3.1.GA tag and the only differences are two places where the missing DefaultCacheFactory.getInstance() call was replaced. If JBC 3 were used as the default in Hibernate 3.4, it should be possible for users to downgrade to JBC 2 as well. They would have to provide their own cache config that doesn't specify MVCC locking, but it should be possible to ensure the hibernate/jbc integration layer doesn't use any JBC 3-specific API. This would require testing of course, most likely via a separate maven profile, which would be something of a pain in the ass. Just want to make sure i fully understand. - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Fri, 2008-10-17 at 16:48 -0500, Brian Stansberry wrote: Just ran the current trunk testsuite for cache-jbosscache2 using JBC 3.0.0.CR1 and there are no problems. However, there are a 21 failures trying to use 3.0.0.CR1 in Hibernate 3.3.1. All seem to be due to the removal of the DefaultCacheFactory.getInstance() method. The failing calls are not in the testsuite; they are in the main code. So, JBC 3 as is will not work in Hibernate 3.3. To have JBC 3 be considered API compatible for inclusion in AS 5.x, this method would need to be restored. Steve Ebersole wrote: I think we should officially move to "inclusion" of JBossCache 3.0 in 3.4 which is not too far off. For 3.3 it is easy enough for users to override Hibernate's declaration of JBossCache version to use 3.0 via Maven *provided* the API really is compatible (drop-in replacement wise) - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Mon, 2008-10-13 at 09:18 -0500, Brian Stansberry wrote: Manik Surtani wrote: Guys, The API of JBC 3.0 is compatible with 2.x so the actual provider code should not change, but we probably want to test MVCC as a locking scheme as well. So, we either 1) need a cache-jbosscache3 module (yuk!), copy the providers and existing tests from cache-jbosscache2 and add a few extra tests. or, 2) assume that cache-jbosscache2 refers to an API and not a version of the cache. So update the cache used in cache-jbosscache2 to 3.0.0, and add the extra MVCC tests as well. My pref would be for 2, what do you guys think? Had a *quick* look at the code, and looks like the only direct use of the JBC node locking scheme is a check for OPTIMISTIC in the JBC config, which if true leads to use of classes that store versions in the cache. With MVCC we don't need to store versions, so looks like the existing logic is fine. If the hibernate guys object to changing the dependency to 3.x, we could look at handling this via a maven profile. If there's no compile time dependency on JBC 3 in the main code or the tests (likely, since MVCC is configured via XML) then we could isolate execution of the MVCC tests in a profile. Downside to the profile approach is the standard JBC configs that ship would still use PESSIMISTIC/OPTIMISTIC. Cheers -- Manik Surtani Lead, JBoss Cache [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Brian Stansberry Lead, AS Clustering 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
Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core
Just ran the current trunk testsuite for cache-jbosscache2 using JBC 3.0.0.CR1 and there are no problems. However, there are a 21 failures trying to use 3.0.0.CR1 in Hibernate 3.3.1. All seem to be due to the removal of the DefaultCacheFactory.getInstance() method. The failing calls are not in the testsuite; they are in the main code. So, JBC 3 as is will not work in Hibernate 3.3. To have JBC 3 be considered API compatible for inclusion in AS 5.x, this method would need to be restored. Steve Ebersole wrote: I think we should officially move to "inclusion" of JBossCache 3.0 in 3.4 which is not too far off. For 3.3 it is easy enough for users to override Hibernate's declaration of JBossCache version to use 3.0 via Maven *provided* the API really is compatible (drop-in replacement wise) - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Mon, 2008-10-13 at 09:18 -0500, Brian Stansberry wrote: Manik Surtani wrote: Guys, The API of JBC 3.0 is compatible with 2.x so the actual provider code should not change, but we probably want to test MVCC as a locking scheme as well. So, we either 1) need a cache-jbosscache3 module (yuk!), copy the providers and existing tests from cache-jbosscache2 and add a few extra tests. or, 2) assume that cache-jbosscache2 refers to an API and not a version of the cache. So update the cache used in cache-jbosscache2 to 3.0.0, and add the extra MVCC tests as well. My pref would be for 2, what do you guys think? Had a *quick* look at the code, and looks like the only direct use of the JBC node locking scheme is a check for OPTIMISTIC in the JBC config, which if true leads to use of classes that store versions in the cache. With MVCC we don't need to store versions, so looks like the existing logic is fine. If the hibernate guys object to changing the dependency to 3.x, we could look at handling this via a maven profile. If there's no compile time dependency on JBC 3 in the main code or the tests (likely, since MVCC is configured via XML) then we could isolate execution of the MVCC tests in a profile. Downside to the profile approach is the standard JBC configs that ship would still use PESSIMISTIC/OPTIMISTIC. Cheers -- Manik Surtani Lead, JBoss Cache [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Brian Stansberry Lead, AS Clustering 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
Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core
Manik Surtani wrote: Guys, The API of JBC 3.0 is compatible with 2.x so the actual provider code should not change, but we probably want to test MVCC as a locking scheme as well. So, we either 1) need a cache-jbosscache3 module (yuk!), copy the providers and existing tests from cache-jbosscache2 and add a few extra tests. or, 2) assume that cache-jbosscache2 refers to an API and not a version of the cache. So update the cache used in cache-jbosscache2 to 3.0.0, and add the extra MVCC tests as well. My pref would be for 2, what do you guys think? Had a *quick* look at the code, and looks like the only direct use of the JBC node locking scheme is a check for OPTIMISTIC in the JBC config, which if true leads to use of classes that store versions in the cache. With MVCC we don't need to store versions, so looks like the existing logic is fine. If the hibernate guys object to changing the dependency to 3.x, we could look at handling this via a maven profile. If there's no compile time dependency on JBC 3 in the main code or the tests (likely, since MVCC is configured via XML) then we could isolate execution of the MVCC tests in a profile. Downside to the profile approach is the standard JBC configs that ship would still use PESSIMISTIC/OPTIMISTIC. Cheers -- Manik Surtani Lead, JBoss Cache [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Brian Stansberry Lead, AS Clustering 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
[hibernate-dev] Re: [jbosscache-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache
Manik Surtani wrote: On 18 Jul 2008, at 16:35, Brian Stansberry wrote: Galder Zamarreno wrote: Paul Ferraro wrote: refresh() always goes to the db, and only potentially triggers a 2LC update - not a read. [OT] A concern I have is whether the refresh() removes the item from the 2LC before doing the subsequent Hibernate cache put(). If not our putForExternalRead() usage will prevent the new value being placed in the cache. Either way this should be tested. In the cache-jbosscache2 module in hibernate-core, probably. Haha! A bit of a kick in the pants. ;) Done. And not a problem, refresh() works as expected. :) Test is in org.hibernate.test.cache.jbc2.functional.PessimisticSessionRefreshTest (optimistic and R_R flavor as well.) BTW for anyone working on this testsuite, this test works by borrowing the infrastructure that sets up two SessionFactories (normally used for replicated tests). I add a simple config tweak that causes the second factory not to use a 2nd level cache. I can then use that factory to update the db w/o affecting the cache -- simulating an external process that changes the db w/o hibernate knowing it. If you have a need for another similar test, this approach is very simple. -- Brian Stansberry Lead, AS Clustering 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
[hibernate-dev] Re: [jbosscache-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache
Galder Zamarreno wrote: Paul Ferraro wrote: refresh() always goes to the db, and only potentially triggers a 2LC update - not a read. [OT] A concern I have is whether the refresh() removes the item from the 2LC before doing the subsequent Hibernate cache put(). If not our putForExternalRead() usage will prevent the new value being placed in the cache. Perhaps we should revisit whether the scenario below warrants the cost of repeatable_read, given that entity eviction from session cache is typically used only to minimize memory usage when iterating through large results, i.e. when an entity is not likely to be re-read within the current transaction. Yes. R_C will be the default config; this stuff is really something to document, and to add an alternate R_R config as a convenience for those who actually need it. See http://opensource.atlassian.com/projects/hibernate/browse/HHH-3390 This whole discussion has me thinking about the use of the OPTIMISTIC configs as the default. The main benefit of OPTIMISTIC is allowing an R_R-like semantic without blocking writes. But it comes as a cost. (Again, we're talking defaults here, not whether O/L is 'supported'.) H, this sounds like a bad practice to me or at least not very performant. Evict/clear something within a transaction and then re-get it. Doing an evict() makes perfect sense in some scenarios (to control memory). Doing a subsequent re-read can easily happen if the logic is complex. (Agreed, if it happens a lot that's a sign of a design flaw in the app.) But to then expect R_R from the second read: that for sure makes it an edge case. Brian, did you use 2nd level cache in your previous use case? No. On Thu, 2008-07-17 at 16:59 -0500, Brian Stansberry wrote: Hmm, good point. Potentially also Session.refresh(...), although I'm not sure if the implementation of that method skips the 2LC and goes right to the db. Paul Ferraro wrote: After thinking this through, the only scenario I can think of where the 2LC would be subject to a repeated read is after a session cache eviction (i.e. via Session.clear() or Session.evict(...)). Without REPEATABLE_READ isolation on the 2LC, any subsequent request withing the same transaction for an evicted entity could return an updated value, if the cache was updated by a concurrent request. Paul On Thu, 2008-07-17 at 12:59 -0500, Brian Stansberry wrote: Can anyone see a reason to use REPEATABLE_READ as the JBoss Cache isolation level in the 2nd level cache use case? I'm not seeing one, and it certainly hurts performance by forcing cache writes to block waiting for an earlier tx that did a read to commit. There are 4 types of data cached: 1) Entities If an entity is read from the 2LC, for the life of the tx it will be cached in the Session, so AIUI there should be no second read during the tx. So no benefit to RR. 2) Collections Same as entities. 3) Queries If an application executes a query twice in the same tx, I wouldn't think they'd expect the same result. In any case, if an update to the query cache is blocking waiting for a tx that previously read the query result to release, the existence of the update that means the underlying entities and their timestamps have changed. So a repeated read of the cached query will just result in it being discarded as out of date anyway. 4) Timestamps Here you don't want an RR semantic. You always want to get the most up-to-date data. Anyone see any holes in my thinking? -- Brian Stansberry Lead, JBoss AS Clustering JBoss, a division of Red Hat ___ jbosscache-dev mailing list [EMAIL PROTECTED] https://lists.jboss.org/mailman/listinfo/jbosscache-dev ___ jbosscache-dev mailing list [EMAIL PROTECTED] https://lists.jboss.org/mailman/listinfo/jbosscache-dev -- Brian Stansberry Lead, AS Clustering 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
[hibernate-dev] Re: [jbosscache-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache
Manik Surtani wrote: AFAIR the last time we discussed this (last summer in Austin with Steve and Gavin) we came to the conclusion that R_C was optimal for the 2LC use case. Yep. I was looking for reasons to flat out say "never use R_R, always R_C" in docs and such. Seems it's a bit more subtle than that. I did neglect to change the default in the AS 5 / Hib 3.3 config files, which will shortly be corrected. On 17 Jul 2008, at 22:59, Brian Stansberry wrote: Hmm, good point. Potentially also Session.refresh(...), although I'm not sure if the implementation of that method skips the 2LC and goes right to the db. Paul Ferraro wrote: After thinking this through, the only scenario I can think of where the 2LC would be subject to a repeated read is after a session cache eviction (i.e. via Session.clear() or Session.evict(...)). Without REPEATABLE_READ isolation on the 2LC, any subsequent request withing the same transaction for an evicted entity could return an updated value, if the cache was updated by a concurrent request. You'd need to check with Steve on this, but to the best of my knowledge, once a session has started, it copies stuff to a "first-level cache" which is a Map associated with the session. A Session.clear()/evict() would only flush the 2LC, the 1LC would still be intact to provide R_R to the caller. Although it does sound a bit odd that a clear() or evict() won't affect 1LC and go straight to 2LC, so I could be wrong. :-) Session.evict() and clear() clear the 1LC.[1] The 2LC is managed via the SessionFactory API. In my now-recollected usage of Session.evict() at my previous employer, we used it to free memory during transactions that processed a lot of data, exactly what [1] describes. So, so far it seems R_R in the cache config only makes sense if: 1) You are using Session.clear() evict() or refresh(). 2) AND your app needs R_R semantics for the entities/collections affected by those calls. AIUI, the whole point of using refresh() is because you don't want R_R semantics [2], so clear() and evict() are the key points. [1] http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-sessioncache [2] http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#objectstate-loading Cheers, Manik -- Manik Surtani Lead, JBoss Cache [EMAIL PROTECTED] -- Brian Stansberry Lead, AS Clustering 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
[hibernate-dev] Re: [jbosscache-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache
Hmm, good point. Potentially also Session.refresh(...), although I'm not sure if the implementation of that method skips the 2LC and goes right to the db. Paul Ferraro wrote: After thinking this through, the only scenario I can think of where the 2LC would be subject to a repeated read is after a session cache eviction (i.e. via Session.clear() or Session.evict(...)). Without REPEATABLE_READ isolation on the 2LC, any subsequent request withing the same transaction for an evicted entity could return an updated value, if the cache was updated by a concurrent request. Paul On Thu, 2008-07-17 at 12:59 -0500, Brian Stansberry wrote: Can anyone see a reason to use REPEATABLE_READ as the JBoss Cache isolation level in the 2nd level cache use case? I'm not seeing one, and it certainly hurts performance by forcing cache writes to block waiting for an earlier tx that did a read to commit. There are 4 types of data cached: 1) Entities If an entity is read from the 2LC, for the life of the tx it will be cached in the Session, so AIUI there should be no second read during the tx. So no benefit to RR. 2) Collections Same as entities. 3) Queries If an application executes a query twice in the same tx, I wouldn't think they'd expect the same result. In any case, if an update to the query cache is blocking waiting for a tx that previously read the query result to release, the existence of the update that means the underlying entities and their timestamps have changed. So a repeated read of the cached query will just result in it being discarded as out of date anyway. 4) Timestamps Here you don't want an RR semantic. You always want to get the most up-to-date data. Anyone see any holes in my thinking? -- Brian Stansberry Lead, JBoss AS Clustering JBoss, a division of Red Hat ___ jbosscache-dev mailing list [EMAIL PROTECTED] https://lists.jboss.org/mailman/listinfo/jbosscache-dev -- Brian Stansberry Lead, AS Clustering 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
[hibernate-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache
Can anyone see a reason to use REPEATABLE_READ as the JBoss Cache isolation level in the 2nd level cache use case? I'm not seeing one, and it certainly hurts performance by forcing cache writes to block waiting for an earlier tx that did a read to commit. There are 4 types of data cached: 1) Entities If an entity is read from the 2LC, for the life of the tx it will be cached in the Session, so AIUI there should be no second read during the tx. So no benefit to RR. 2) Collections Same as entities. 3) Queries If an application executes a query twice in the same tx, I wouldn't think they'd expect the same result. In any case, if an update to the query cache is blocking waiting for a tx that previously read the query result to release, the existence of the update that means the underlying entities and their timestamps have changed. So a repeated read of the cached query will just result in it being discarded as out of date anyway. 4) Timestamps Here you don't want an RR semantic. You always want to get the most up-to-date data. Anyone see any holes in my thinking? -- Brian Stansberry Lead, JBoss AS Clustering JBoss, a division of Red Hat ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Clustering and UpdateTimestampsCache
Wanted to raise a point about about timestamps cache handling in case
there's any desire to change the UpdateTimestampsCache API in 3.3.
AIUI, a goal of UpdateTimestampsCache is to ensure the cached timestamp
never moves backward in time *except* when a caller that has set the
timestamp to a far-in-the-future value in preInvalidate() later comes
back and calls invalidate(), passing the current time.
There's a race in UpdateTimestampsCache where this could break under
concurrent load. For example, you could see:
(now = 0)
tx1 : preInvalidate(60);
(now = 1)
tx2 : preInvalidate(61);
tx1 : cache queryA w/ timestamp 1
tx1 : invalidate(1)
tx2 : update entity in a way that would query A results
tx2 : read queryA; check timestamp; 1 == 1 so passes. Wrong!
To deal with this, there are some comments in UpdateTimestampsCache
about having preInvalidate() return some sort of Lock object, which
would then be returned as a param to invalidate(). Idea here is to
ensure that only the caller that most recently called preInvalidate is
allowed to call invalidate.
That could work if the backing TimestampsRegion isn't clustered, but it
doesn't address the fact that a clustered TimestampsRegion can be
getting updates not only via the local UpdateTimestampsCache, but also
asynchronously over the network. If a clustered TimestampsRegion gets a
replicated update that moves the timestamp back in time, it has no
simple way to know if this is because 1) a peer that earlier replicated
a high preinvalidate value is now replicating a normal invalidate
value or 2) an earlier change from peer A has arrived *after* a later
change from peer B.
This could be addressed with a change to the TimestampsRegion API.
Basically replace
public void put(Object key, Object value) throws CacheException;
with
public void preInvalidate(Object key, Object value) throws CacheException;
public void invalidate(Object key, Object value, Object
preInvalidateValue) throws CacheException;
Basically the value that is passed to preInvalidate is also passed as a
2nd param to invalidate. This gives the TimestampsRegion the
information it needs to properly track preinvalidations vs invalidations.
The UpdateTimestampsCache API is then changed to provide the caller with
the timestamp in preInvalidate() and take it back in invalidate():
public synchronized Object preinvalidate(Serializable[] spaces) throws
CacheException {
Long ts = new Long( region.nextTimestamp() + region.getTimeout() );
for ( int i=0; ipublic synchronized void invalidate(Serializable[] spaces, Object
preInvalidateValue) throws CacheException {
Long ts = new Long( region.nextTimestamp() );
for ( int i=0; iThis is basically similar to the Lock concept in the
UpdateTimestampsCache comments; but the control over the update is
delegated to the TimestampsRegion.
The issue here is the UpdateTimestampsCache caller needs to hold onto
the value returned by preInvalidate() and then pass it back. Likely
requires a change to Executable to provide a holder for it.
A change to the TimestampsRegion API has no benefit without a
corresponding change in UpdateTimestampsCache and its caller.
--
Brian Stansberry
Lead, AS Clustering
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
[hibernate-dev] JBoss Cache 2.0 Integration
Hi Steve,
Need to touch base with you on the semantics for the JBC 2.0 integration.
1) QueryResultsRegionImpl
In the JBC 1.x impl, the get() and put() operations invoked from
StandardQueryCache suspended any tx before accessing the cache. In the
QueryResultsRegionImpl I've written I do the same, mostly to be consistent.
Good: Locks are not held in JBC for the life of a tx, so you don't get a
tx2 trying to read the cache blocking for a long-running tx1 that cached
a query result.
Bad: That tx2 can see the query results from tx1. Those results might
reflect uncommitted changes made by tx1.
Bad: The tx1 changes are replicated around the cluster as soon as they
are put in the cache, rather than at tx commit. More replication
messages, plus other nodes also see the uncommitted changes.
One possible solution I see to this is to not suspend the tx for put(),
and also pass a 0 ms timeout option to JBC for both get() and put().
Basically, don't block in the face of contention; just timeout and fail
silently. What do you think of this? (Doing this is going to require
addition of a new Option to JBC though.)
2) EntityRegionImpl
I noticed your impl of get() does not suspend any tx, which is different
from the old behavior. So, a get() call will cause a read lock in the
cache that will block any other tx doing an update. Was this intentional?
If it was intentional, it leads to an odd situation when putFromLoad is
called with minimalPutOverride=true
if ( minimalPutOverride && get( key, txTimestamp ) != null ) {
return false;
}
return putFromLoad( key, value, txTimestamp, version );
The get( key, txTimestamp ) call could block, while a regular
putFromLoad won't. So, if minimalPutOverride=true the call might block,
while if minimalPutOverride=false, it won't. That seems odd.
3) TimestampsRegionImpl
Here, suspending the tx on both get() and put() makes total sense. To
ensure the desired async replication though, I'm going to have to add a
new Option to JBC. Until that's done, the timestamps will replicate
synchronously if the timestamps cache is using the same cache as
entities/collections. :(
Good news here is I think I've solved an old problem where async
replication could result in timestamps going back in time.
TimestampsRegionImpl now maintains an internal timestamp map, and just
uses JBC as a replication layer. No change is allowed to the internal
timestamp map unless it *increases* the timestamp.
--
Brian Stansberry
Lead, AS Clustering
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
Re: [hibernate-dev] EJB3/Hibernate/JBoss Cache intergration broken in EJB3 trunk
Christian Bauer wrote: On Jul 2, 2007, at 4:58 PM, Brian Stansberry wrote: FYI, there are a bunch of EJB3 clustered entity test failures in AS trunk due to a bad interaction between Hibernate 3.2.4.SP1 and JBoss Cache 2.0.0. Basically, this is a temporary mismatch between Hibernate and JBC. There's work in Hibernate Core's trunk for the 3.3 release that can let us resolve this, but for now the tests are going to fail. Problem is the integration layer ends up calling the JBC putForExternalRead() method when it needs to cache something in the "UpdateTimestampsCache". JBC treats a calls to this method as a no-op if the cache node in question already exists. This is new behavior in JBC 2.0. It's the necessary and intended behavior when the method is called for caching entities and collections. But when it's called for the UpdateTimestampsCache, it causes problems. The Hibernate 3.3. codebase gives us the flexibility to call a different method for the UpdateTimestampsCache call; to fix the problem we need determine the exact behavior we want for the UpdateTimestampsCache call and make the appropriate call to JBC. Can we put this on the JBoss Cache/Hibernate wiki page with a final conclusion and guidelines for current users of both? I added a version of the above to http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernateAlignment. As mentioned there, a bunch of us will be meeting the week of July 23 to deal with these issues. We'll update the wiki after those discussions. As for "current users of both", the only code I'm aware of that currently tries to integrate Hibernate and JBC 2.0 is the EJB3 stuff in AS trunk. Unless I hear about an impending release off that code base, I intend to leave that as is until we sort it out at the end of the month. There is a "cache-jbosscache2" directory structure in Hibernate Core trunk, but at the moment that's empty. -- Brian Stansberry Lead, AS Clustering 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
[hibernate-dev] EJB3/Hibernate/JBoss Cache intergration broken in EJB3 trunk
Carlo, FYI, there are a bunch of EJB3 clustered entity test failures in AS trunk due to a bad interaction between Hibernate 3.2.4.SP1 and JBoss Cache 2.0.0. Basically, this is a temporary mismatch between Hibernate and JBC. There's work in Hibernate Core's trunk for the 3.3 release that can let us resolve this, but for now the tests are going to fail. Problem is the integration layer ends up calling the JBC putForExternalRead() method when it needs to cache something in the "UpdateTimestampsCache". JBC treats a calls to this method as a no-op if the cache node in question already exists. This is new behavior in JBC 2.0. It's the necessary and intended behavior when the method is called for caching entities and collections. But when it's called for the UpdateTimestampsCache, it causes problems. The Hibernate 3.3. codebase gives us the flexibility to call a different method for the UpdateTimestampsCache call; to fix the problem we need determine the exact behavior we want for the UpdateTimestampsCache call and make the appropriate call to JBC. -- Brian Stansberry Lead, AS Clustering 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
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
Max Rydahl Andersen wrote: 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 ? You mean one with a multiplexer? Right now a multiplexer gets injected into the cache; JBC has no mechanism to create one itself. Sounds like we'll need to deal with that. 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 ? Just that JG 2.5 requires JDK 5. AIUI, Hibernate 3.3 will support JDK 1.4. JBC 2.0 will have a retroweaved version that works with JDK 1.4 and that should work fine with JGroups 2.4.x. So, you can make Hibenate 3.3 + JBC work on JDK 1.4, but the multiplexer stuff won't work well. Confusing. Re: #4 : what exactly are these differences? Now is the time to merge it back... 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. Yes, this was a hack to allow EJB3 entity clustering to work when people didn't specify a region prefix. (See below for more on why that's an issue). I certainly wouldn't mind seeing this go away. Isn't it better to just use hibernate.cache.region_prefix to disambiguate the regions per sessionfactory ? Sure. IIRC, if you specify a region_prefix that becomes part of the region name passed to o.h.c.TreeCache, in which case the hack that prevents replication would be bypassed. 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. JBoss AS currently deploys a single JBC instance for use as a shared cache across EJB3 deployments. If you specify org.jboss.ejb3.entity.TreeCacheProviderHook, that's what you get unless you go out of your way to deploy a separate cache. The design decisions that led to doing it that way predate me, but I assume its due to the hassle of deploying multiple JGroups channels. 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 ? :) I think he's teaching this week?? -- Brian Stansberry Lead, AS Clustering 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
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
Steve Ebersole wrote:
Re: #4 : what exactly are these differences? Now is the time to
merge it back...
Forgot to attach the diff to my last message. Here it is.
- Brian
---
C:\dev\hibernate\Branch_3_2\Hibernate3\src\org\hibernate\cache\TreeCache.java
Mon Feb 19 17:05:11 2007
+++ C:\dev\jboss\jboss-4.2\ejb3\src\main\org\jboss\ejb3\entity\JBCCache.java
Mon Feb 19 17:12:35 2007
@@ -1,5 +1,25 @@
-//$Id: TreeCache.java 9965 2006-05-30 18:00:28Z [EMAIL PROTECTED] $
-package org.hibernate.cache;
+/*
+ * JBoss, Home of Professional Open Source.
+ * Copyright 2006, Red Hat Middleware LLC, and individual contributors
+ * as indicated by the @author tags. See the copyright.txt file in the
+ * distribution for a full listing of individual contributors.
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License as
+ * published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this software; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
+ */
+package org.jboss.ejb3.entity;
import java.util.HashMap;
import java.util.Iterator;
@@ -12,17 +32,24 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import org.hibernate.cache.Cache;
+import org.hibernate.cache.CacheException;
+import org.hibernate.cache.StandardQueryCache;
+import org.hibernate.cache.UpdateTimestampsCache;
import org.jboss.cache.Fqn;
+import org.jboss.cache.config.Option;
import org.jboss.cache.lock.TimeoutException;
/**
- * Represents a particular region within the given JBossCache TreeCache.
+ * Subclass of the standard org.hibernate.cache.TreeCache used as
+ * a workaround until issues related to JBCLUSTER-150 are resolved in
Hibernate.
*
* @author Gavin King
+ * @author Brian Stansberry
*/
-public class TreeCache implements Cache {
+public class JBCCache implements Cache {
- private static final Log log = LogFactory.getLog(TreeCache.class);
+ private static final Log log = LogFactory.getLog(JBCCache.class);
private static final String ITEM = "item";
@@ -30,13 +57,40 @@
private final String regionName;
private final Fqn regionFqn;
private final TransactionManager transactionManager;
+private boolean localWritesOnly;
- public TreeCache(org.jboss.cache.TreeCache cache, String regionName,
TransactionManager transactionManager)
+ public JBCCache(org.jboss.cache.TreeCache cache, String regionName,
TransactionManager transactionManager)
throws CacheException {
this.cache = cache;
this.regionName = regionName;
this.regionFqn = Fqn.fromString( regionName.replace( '.', '/' )
);
this.transactionManager = transactionManager;
+if (cache.getUseRegionBasedMarshalling())
+{
+ localWritesOnly =
StandardQueryCache.class.getName().equals(regionName);
+
+ boolean fetchState = cache.getFetchInMemoryState();
+ try
+ {
+ // We don't want a state transfer for the StandardQueryCache,
+ // as it can include classes from multiple scoped classloaders
+ if (localWritesOnly)
+ cache.setFetchInMemoryState(false);
+
+ // We always activate
+ activateCacheRegion(regionFqn.toString());
+ }
+ finally
+ {
+ // Restore the normal state transfer setting
+ if (localWritesOnly)
+ cache.setFetchInMemoryState(fetchState);
+ }
+}
+else
+{
+ log.debug("TreeCache is not configured for region based
marshalling");
+}
}
public Object get(Object key) throws CacheException {
@@ -60,7 +114,14 @@
public void update(Object key, Object value) throws CacheException {
try {
- cache.put( new Fqn( regionFqn, key ), ITEM, value );
+if (localWritesOnly) {
+ Option option = new Option();
+ option.setCacheModeLocal(true);
+ cache.put( new Fqn( regionFqn, key ), ITEM, value, option );
+}
+else {
+cache.put( new Fqn( regionFqn, key ), ITEM, value );
+}
Re: [hibernate-dev] Re: JBoss Cache and Hibernate Integration
n 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 -- Brian Stansberry Lead, AS Clustering 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
[hibernate-dev] Re: JBoss Cache and Hibernate Integration
OK, Monday 9/26 at 10:00 AM EST it is. Details below. Manik, you had a problem today joining a conf Ram set up using the # below; you guys overseas might test it during your Monday and if there's an issue send me a note by 9:30 EST or so. Main things to discuss are on http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernateAlignment. Participant Passcode: 426146 Listen-only Passcode: 4261469 Phone Numbers: Toll free: 1-866-863-0570 Toll: 1-719-785-1839 Local (Australia, Sydney): + 61 282078345 Local (Austria, Vienna): + 43 2 682 205 6473 Local (Belgium, Brussels): + 32 2 789 7404 Local (Denmark, Copenhagen): + 45 32 71 49 78 Local (France, Paris): + 33 1 7304 1405 Local (Germany, Frankfurt): + 49 69 36507 2085 Local (Hong Kong): + 852 300 80 305 Local (Ireland, Dublin): + 353 1 436 7678 Local (Italy, Milan): + 39 02 896 291 98 Local (Italy, Rome): + 39 06 452 108 385 Local (Italy, Turin): + 39 01 121 792 109 Local (Japan, Tokyo): + 813 4455 1255 Local (Netherlands, Amsterdam): + 31 20 794 8154 Local (Singapore): + 65 64193725 Local (Spain, Barcelona): + 34 93 492 3169 Local (Spain, Madrid): + 34 91 788 9790 Local (Spain, Valencia): + 34 96 047 3045 Local (Sweden, Stockholm): + 46 8 5052 0391 Local (Switzerland, Geneva): + 41 22 592 7323 Local (Switzerland, Zurich): + 41 43 456 9168 Local (UK, London): + 44(0) 207 663 2215 International toll free (Argentina): 0 800 666 2108 International toll free (Australia): 1 800 069 181 International toll free (Austria): 0 800 295 856 International toll free (Bahamas): 1 800 389 0432 International toll free (Belgium): 0 800 73 378 International toll free (Brazil): 0 800 891 9738 International toll free (Chile): 123 0020 6923 International toll free (China, Northern Region): 10 800 714 0955 International toll free (China, Southern Region): 10 800 140 0931 International toll free (Colombia): 01 800 518 0492 International toll free (Costa Rica): 0 800 015 0454 International toll free (Czech Republic): 800 142 019 International toll free (Denmark): 80 887 261 International toll free (Dominican Republic): 1 888 751 4409 International toll free (France): 0 800 908 359 International toll free (Germany): 0 800 182 1595 International toll free (Greece): 00 800 161 2205 1625 International toll free (Hong Kong): 800 933 791 International toll free (Hungary): 06 800 184 16 International toll free (India): 000 800 1006 397 International toll free (Indonesia): 001 803 017 1625 International toll free (Ireland): 1 800 760 193 International toll free (Israel): 1 80 945 1625 International toll free (Italy): 800 870 328 International toll free (Japan): 00531 16 0605 International toll free (Latvia): 800 2487 International toll free (Lithuania): 8 800 9 00 62 International toll free (Luxembourg): 800 2 5774 International toll free (Malaysia): 1 800 812 593 International toll free (Mexico): 001 800 514 1625 International toll free (Monaco): 800 93 297 International toll free (Netherlands): 0 800 022 2653 International toll free (New Zealand): 0 800 450 433 International toll free (Norway): 800 192 42 International toll free (Panama): 00 800 226 1625 International toll free (Poland): 00 800 111 48 26 International toll free (Portugal): 800 819 366 International toll free (Russia): 810 800 2535 1012 International toll free (Singapore): 800 101 1767 International toll free (Slovenia): 0 800 80802 International toll free (South Africa): 0 800 999 571 International toll free (South Korea): 003 0813 1634 International toll free (Spain): 900 987 056 International toll free (Sweden): 02 079 5157 International toll free (Switzerland): 0 800 562 271 International toll free (Thailand): 001 800 156 205 1625 International toll free (Trinidad-Tobago): 1 800 205 1625 International toll free (UK): 0 800 051 3876 International toll free (Uruguay): 0004 019 0088 International toll free (Venezuela): 0 800 100 5202 Manik Surtani wrote: +1 On 22 Feb 2007, at 18:19, Steve Ebersole wrote: Brian Stansberry wrote: Sent this out a while back, but the conf call didn't come off due to scheduling issues. Time to try again. How does next Monday, Feb 26 at 10:00 AM EST sound? Once we have an agreed time I'll send out conference call details. Those cc'ed on the mailing lists are welcome to join in. Also including Owen explicitly, since I am not sure if he is part of either list. That date/time is fine for me. -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: [EMAIL PROTECTED] Telephone: +44 7786 702 706 MSN: [EMAIL PROTECTED] Yahoo/AIM/Skype: maniksurtani -- Brian Stansberry Lead, AS Clustering 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
[hibernate-dev] RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate
+1. After I wrote the below I thought about the fact that it's the AS that adds the classloading complexity that exposes some issues. So the AS needs to be sure to exercise things, well above and beyond the basic requirements. Still, it's important to realize that AFAICT the JBoss EJB3 layers add very little on top of what comes with Hibernate (including Hibernate EntityManager). So I want to be sure we don't get into a situation where EJB3 tests are substituting for tests in Hibernate (or JBC), because by the time the EJB3 tests get run on new Hibernate/JBC releases, it's likely to be near the end of their release cycle. Manik Surtani wrote: > +1 on all these points, including a compat matrix that Galder > suggested. > > Perhaps the binding 'glue' to this should be the AS, since > moving forward (with AS5), we will have integration between > the EJB3 entity beans and JBC. We will have more tests > within the JBC suite to consider the entity bean use case, > and I'm sure Hibernate will add more tests to their suite to > deal with 2nd level caching vagaries specific to JBC, but I'd > like to see some on the AS level (like we have with tomcat > session clustering) which can act as a driver to integrate > the 2 pieces. > > Thoughts? > >> My thoughts on this: >> >> 1) IMO the Hibernate use case for entity caching is really a standard >> use case for JBC, and thus should be thoroughly simulated in the JBC >> test suite. 2) In general, a component that integrates another >> component should have basic tests of its usage of that component in >> its own test suite. These tests need to be more thorough if there is >> any non- trivial integration layer, which Hibernate certainly has on >> top of JBC. Thus Hibernate should have tests of JBC as a 2nd level >> cache that cover all aspects of its use. 3) Hibernate is a major JBC >> consumer, akin to the AS. Thus, before a JBC release goes out (at >> least a CR), a Hibernate release with which it is meant to integrate >> should be identified. Part of the QA process for the JBC release >> should be to run the Hibernate testsuite using the new JBC release. >> Same as what we do for the AS. 4) Higher level services built on top >> of Hibernate/EJB (e.g. EJB3) should follow the same principles with >> respect to Hibernate as #2 above. >> >> >> Galder Zamarreno wrote: >>> +10 on JBC/Hibernate integration testing too, but whose >>> responsibility +would be to deal with them and make sure that they >>> work? Hibernate or +JBC developer's? Rather than splitting >>> responsibility, I >>> think it'd be >>> +easier to have someone in charge of it who would lease with >>> the rest of >>> +Hibernate and JBC developers, but this is different topic >>> already... +:-) >>> >>> I sent an email a month ago about the possibility of creating a >>> Hibernate/JBC compatibility matrix but not a single person replied. >>> These tests would give us the information we need for this. >>> >>> Galder Zamarreño >>> Sr. Software Maintenance Engineer >>> JBoss, a division of Red Hat >>> >>> IT executives: Red Hat still #1 for value >>> http://www.redhat.com/promo/vendor/ >>> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Brian >>> Stansberry Sent: 17 November 2006 16:44 >>> To: Manik Surtani >>> Cc: [EMAIL PROTECTED] >>> Subject: RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the >>> JBoss EJBContainer] - Problemwith order of entity cache operations >>> withHibernate >>> >>> +10 on JBC/Hibernate integration testing. >>> >>> The EJB3 testsuite has one test in this area, which luckily >>> uncovered the issue. Only uses the TM that's integrated in the AS; >>> it was a lucky hit. >>> >>> There should be more EJB3 tests as well, but the primary place for >>> it should be in Hibernate/JBC. E.g. this issue quite likely >>> impacts non-EJB3 Hibernate as well. >>> >>> That's how we find such a thing. Anyone have any good thoughts on >>> what to do about it? Perhaps Hibernate exposes something like JBC's >>> OrderedSynchronizationHandler, which the JBC integration can use to >>> insert it's synchronization at the correct point? >>> >>> Manik Surtani wrote: >>>> Hmm, the *correct* approach to dealing with this would be to put >>>> together a s
[hibernate-dev] RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate
My thoughts on this: 1) IMO the Hibernate use case for entity caching is really a standard use case for JBC, and thus should be thoroughly simulated in the JBC test suite. 2) In general, a component that integrates another component should have basic tests of its usage of that component in its own test suite. These tests need to be more thorough if there is any non-trivial integration layer, which Hibernate certainly has on top of JBC. Thus Hibernate should have tests of JBC as a 2nd level cache that cover all aspects of its use. 3) Hibernate is a major JBC consumer, akin to the AS. Thus, before a JBC release goes out (at least a CR), a Hibernate release with which it is meant to integrate should be identified. Part of the QA process for the JBC release should be to run the Hibernate testsuite using the new JBC release. Same as what we do for the AS. 4) Higher level services built on top of Hibernate/EJB (e.g. EJB3) should follow the same principles with respect to Hibernate as #2 above. Galder Zamarreno wrote: > +10 on JBC/Hibernate integration testing too, but whose responsibility > +would be to deal with them and make sure that they work? > Hibernate or > +JBC developer's? Rather than splitting responsibility, I > think it'd be > +easier to have someone in charge of it who would lease with > the rest of > +Hibernate and JBC developers, but this is different topic already... > +:-) > > I sent an email a month ago about the possibility of creating > a Hibernate/JBC compatibility matrix but not a single person > replied. These tests would give us the information we need for this. > > Galder Zamarreño > Sr. Software Maintenance Engineer > JBoss, a division of Red Hat > > IT executives: Red Hat still #1 for value > http://www.redhat.com/promo/vendor/ > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Brian Stansberry > Sent: 17 November 2006 16:44 > To: Manik Surtani > Cc: [EMAIL PROTECTED] > Subject: RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design > of the JBoss EJBContainer] - Problemwith order of entity > cache operations withHibernate > > +10 on JBC/Hibernate integration testing. > > The EJB3 testsuite has one test in this area, which luckily > uncovered the issue. Only uses the TM that's integrated in > the AS; it was a lucky hit. > > There should be more EJB3 tests as well, but the primary > place for it should be in Hibernate/JBC. E.g. this issue > quite likely impacts > non-EJB3 Hibernate as well. > > That's how we find such a thing. Anyone have any good > thoughts on what to do about it? Perhaps Hibernate exposes > something like JBC's OrderedSynchronizationHandler, which the > JBC integration can use to insert it's synchronization at the correct > point? > > Manik Surtani wrote: >> Hmm, the *correct* approach to dealing with this would be to put >> together a series of integration tests for JBoss Cache and Hibernate, >> exercising such scenarios with different TMs, and making sure these >> are run with every release of Hibernate and JBC. Either that, or we >> assume the EJB3 test suite covers this, and I presume this is how >> you uncovered this issue? >> >> >>> FYI; just posted on the EJB3 forum. >>> >>> [EMAIL PROTECTED] wrote: >>>> There appears to be a difference in behavior between JBossTM and >>>> JBossTS that's leading to failures with JBoss Cache as the 2nd >>>> level entity cache. >>>> >>>> JBC handles replication of transaction-scoped cache changes by >>>> registering as a transaction Synchronization and replicating the >>>> changes during the beforeCompletion() callback. This is failing >>>> with JBossTS because the beforeCompletion() callback is being >>>> executed *before* the Hibernate flush activity that updates the >>>> cache. No activity at time of beforeCompletion() == no >>>> replication of the tx's changes. >>>> >>>> 2006-11-16 23:48:41,250 TRACE >>>> [org.jboss.cache.interceptors.TxInterceptor] Running >>>> beforeCompletion on gtx GlobalTransaction:<192.168.1.164:2668>:1 >>>> 2006-11-16 23:48:41,250 TRACE >>>> [org.jboss.cache.interceptors.TxInterceptor] Setting up >>>> transactional context. 2006-11-16 23:48:41,250 TRACE >>>> [org.jboss.cache.interceptors.TxInterceptor] Setting tx as >>>> TransactionImple < ac, BasicAction: >> -3f57ff9b:a5b:455d4cd6:10 status: >>>> 0 > and gtx as GlobalTransaction:<192.168.1.164:2668>:1 2006-11-16 >
[hibernate-dev] RE: Replication problems with query cache and JBoss Cache
Follow up to this earlier thread...
Using the JBC classloader registration API won't work right now due to
http://jira.jboss.com/jira/browse/JBCACHE-876. With the query cache, a
user class can end up as part of an Fqn; JBC doesn't deal with this yet.
The RH stacks people are looking for a solution this week; one
workaround idea I had was to use persistence.xml to replace the
StandardQueryCacheFactory with a custom one. This custom QueryCache
would use the JBC Option API to make all writes to JBC for the query
cache local only (i.e. non-replicated).
The entity cache and update timestamps cache would still replicate.
Do you guys see any problem with such an approach (besides ugliness);
e.g. any problems with the non-replicated query caches falling out of
sync with the entities?
- Brian
Brian Stansberry wrote:
> Steve Ebersole wrote:
>> (1)
>>
>> The FQN is exactly the regionName value passed in to
>> CacheProvider.buildCache(). The structure of the region names are
>> determined by the callers of this method, and it is different based
>> on the intended usage of the built region.
>>
>> For entity caches the region name follows the pattern:
>> {prefix.}rootEntityName
>>
>> For collection caches the pattern is:
>> {prefix.}owningEntityName.collectionPropertyName
>>
>> For query caches, there is a default which is named:
>> {prefix.}org.hibernate.cache.StandardQueryCache
>>
>> although users can specify additional query cache regions:
>> {prefix.}userSuppliedRegionName
>>
>
> Carlo, for an EJB3 entity deployment where the query cache is
> enabled, is there a separate query cache region set up for
> that deployment? Or is the default one used? If the former,
> we can register the proper classloader for each query cache
> region. If the latter, there is no single correct
> classloader for the default region and we have a problem.
>
>> The dots are transformed to slashes for TreeCache based providers;
>> although note that there was a bug in how this was done early which
>> caused a very flat structure. The nodes were named correctly, but
>> apparently we were not constructing the actual FQN correctly causing
>> all regions to be created flat off of the root node.
>>
>>
>> (2)
>>
>> The vast majority of cache regions are built when the SessionFactory
>> is being built. So this is probably done during deployment. I
>> assume EJB3 deployer properly sets up a context classloader, though
>> not certain. But regardless, the classloader used would need access
>> to the entity classes as they would be need during construction of
>> the SessionFactory anyway. Typically deployers in JBoss are pretty
>> smart and switch to the *deployment's* classloader before invoking
>> on the deployment...
>
> Yeah, I figured that's the case.
>
>> -Original Message-
>> From: Brian Stansberry
>> Sent: Tuesday, November 14, 2006 11:23 AM
>> To: Steve Ebersole; Max Andersen
>> Subject: FW: Replication problems with query cache and JBoss Cache
>>
>> Guys,
>>
>> I've tried sending the following to hibernate-dev a couple times and
>> it rejects me (I registered), so I'll just send it to you directly.
>>
>> Brian Stansberry wrote:
>>> There are some classloader issues with JBoss Cache's deserialization
>>> of replicated query cache entries (see
>>> http://jira.jboss.com/jira/browse/JBCLUSTER-150). I'm hoping these
>>> will be pretty easy to resolve using some JBC APIs meant for this
>>> kind of problem, but need confirmation on a couple points:
>>>
>>> 1) What's the structure of the Fqn where query cache entries are
>>> stored in JBC? Specifically, how does it relate to the regionName
>>> parameter that's passed to CacheProvider.buildCache(String
>>> regionName, Properties properties)? Logically, is it something
>>> like:
>>>
>>> /somepath/regionName/queryCache/entry
>>> /somepath/regionName/entityCache/entry
>>>
>>> or..
>>>
>>> /somepath/queryCache/regionName/entry
>>> /somepath/entityCache/regionName/entry
>>>
>>> or (I hope not)
>>>
>>> /somepath/queryCache/entry
>>> /somepath/entityCache/regionName/entry
>>>
>>> 2) What's the thread context class loader when
>>> CacheProvider.buildCache() is invoked? (I'm thinking here about an
>>> EJB3 entity bean deployment. Probably better asked on the JBoss
>>&g
