overriding target through annotations
by Emmanuel Bernard
I'm looking at ANN-422
In HA, the target is usually inferred from the API (generics), and can
be overridden in all associations through targetEntity (
@ManyToOne(targetEntity...) )
currently, you cannot override the target for a component, nor you can
override it for a <map-key-many-to-many/>
Two solutions
1.
Define a @Target annotation that will work like the targetEntity for
association and also handle components (@Embedded)
Define a @MapKeyTarget to override the <map-key-many-to-many/> or
<map-key/> (composite-element) target
2.
Define a @Target annotation that will work like the targetEntity for
association and also handle components (@Embedded)
add a targetElement to @MapKey and @MapKeyManyToMany annotations
I don't like much 2 because it mixes physical concerns and logical ones,
but it reduce the amount of needed annotations
Note that I hope the future spec will hopefully handle all cases nicely
(ie add a targetElement in @Embedded), @MapKey should go to back the
drawing board from a spec POV so we can think of something clean from
the begining.
Any preference, or alternative solution?
17 years, 11 months
hibernate mysql testsuite
by Aleksandar Kostadinov
I've already sent this, but got no answer. Please take a look at it.
Take a look at the hibernate mysql tests:
http://cruisecontrol.jboss.com/cc/buildresults/hibernate-mysql-testsuite
There are much failings.
As the testsuite was continually failing because of a mysql bug that is
fixed in 4.1.18 I think it's worth installing newer version.
Could you suggest which version will best suite your needs (4.1.latest,
5.0.latest)?
btw. hibernate can be tested against innodb and myisam. Currently it is
tested only against innodb. Is this ok?
Thanks,
Aleksandar Kostadinov
17 years, 12 months
RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate
by Brian Stansberry
+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: jbosscache-dev-bounces(a)lists.jboss.org
>>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Brian
>>> Stansberry Sent: 17 November 2006 16:44
>>> To: Manik Surtani
>>> Cc: jbosscache-dev(a)lists.jboss.org
>>> 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.
>>>>>
>>>>> bstansberry(a)jboss.com 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 23:48:41,250 TRACE
>>> [org.jboss.cache.interceptors.TxInterceptor] No
>>>>>> modifications in this tx. Skipping beforeCompletion()
>>>>>> 2006-11-16 23:48:41,250 DEBUG
>>>>>> [org.hibernate.event.def.AbstractFlushingEventListener]
>>>>>> processing flush-time cascades 2006-11-16 23:48:41,250 DEBUG
>>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] dirty
>>>>>> checking collections 2006-11-16 23:48:41,265 DEBUG
>>>>>> [org.hibernate.engine.Collections] Collection found:
>>>>>>
> [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: []
>>>>>> (initialized) 2006-11-16 23:48:41,265 DEBUG
>>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed:
>>>>>> 3 insertions, 0 updates, 0 deletions to 3 objects 2006-11-16
>>>>>> 23:48:41,265 DEBUG
>>>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed:
>>>>>> 1 (re)creations, 0 updates, 0 removals to 1 collections ...
>>>>>> followed by puts into the cache
>>>>>>
>>>>>> When I switched the AS back to using JBossTM, the problem went
>>>>>> away -- the Hibernate flush activity occurred first, and then the
>>>>>> beforeCompletion() call to JBC.
>>>>>>
>>>>>> I'm speculating that Hibernate is also using a Synchronization to
>>>>>> manage the flush, and that JBossTA and JBossTS make the calls to
>>>>>> registered Synchronizations in a different order.
>>>>>>
>>>>>> At this point, replication of clustered EJB3 entities is
>>>>>> basically broken.
>>>>>>
>>>>>> View the original post :
>>>>>>
>>>>> http://www.jboss.com/index.html?
>>>>> module=bb&op=viewtopic&p=3986745#3986745
>>>>>>
>>>>>> Reply to the post :
17 years, 12 months
RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate
by Brian Stansberry
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: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Brian Stansberry
> Sent: 17 November 2006 16:44
> To: Manik Surtani
> Cc: jbosscache-dev(a)lists.jboss.org
> 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.
>>>
>>> bstansberry(a)jboss.com 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
>>>> 23:48:41,250 TRACE
> [org.jboss.cache.interceptors.TxInterceptor] No
>>>> modifications in this tx. Skipping beforeCompletion() 2006-11-16
>>>> 23:48:41,250 DEBUG
>>>> [org.hibernate.event.def.AbstractFlushingEventListener] processing
>>>> flush-time cascades 2006-11-16 23:48:41,250 DEBUG
>>>> [org.hibernate.event.def.AbstractFlushingEventListener] dirty
>>>> checking collections 2006-11-16 23:48:41,265 DEBUG
>>>> [org.hibernate.engine.Collections] Collection found:
>>>> [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: []
>>>> (initialized) 2006-11-16 23:48:41,265 DEBUG
>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 3
>>>> insertions, 0 updates, 0 deletions to 3 objects 2006-11-16
>>>> 23:48:41,265 DEBUG
>>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1
>>>> (re)creations, 0 updates, 0 removals to 1 collections ... followed
>>>> by puts into the cache
>>>>
>>>> When I switched the AS back to using JBossTM, the problem went away
>>>> -- the Hibernate flush activity occurred first, and then the
>>>> beforeCompletion() call to JBC.
>>>>
>>>> I'm speculating that Hibernate is also using a Synchronization to
>>>> manage the flush, and that JBossTA and JBossTS make the calls to
>>>> registered Synchronizations in a different order.
>>>>
>>>> At this point, replication of clustered EJB3 entities is basically
>>>> broken.
>>>>
>>>> View the original post :
>>>>
>>> http://www.jboss.com/index.html?
>>> module=bb&op=viewtopic&p=3986745#3986745
>>>>
>>>> Reply to the post :
>>>>
>>> http://www.jboss.com/index.html?
>>> module=bb&op=posting&mode=reply&p=398674
>>> 5
>>>> _______________________________________________
>>>> jboss-dev-forums mailing list
>>>> jboss-dev-forums(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 12 months
