Re: [hibernate-dev] HHH-7018 and one more change to how we serialize EntityManagerFactory instances...
On Feb 7, 2012, at 16:05 , Scott Marlow wrote: > The use case for duplicate EntityManagerFactory, would be the application > that is depending on the persistence unit name that may or may not be > unique across multiple application deployments. Or many integration test environments. Test setups which didn't have to use EMF.close() now have to close the EMF in @AfterTest/Class/Method to avoid the "duplicate EMF name registered" WARN level message. First question here is why this would be a warning message, if I'm not interested in clustering. Then I'm not sure caching anything at the classloader level is a good choice. (For whatever reason, I still don't understand why EMF clustering would be different than SF clustering.) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [Search] ParameterizedBridge API
The current API reads:
public interface ParameterizedBridge {
//TODO inject Properties? since the annotations cannot support Object
attribute?
void setParameterValues(Map parameters);
}
Shall we apply the TODO, or at least change it to specify the expected
Map types?
public interface ParameterizedBridge {
void setParameterValues(Map parameters);
}
Using generics we would keep backwards compatibility.
I'm looking at this because we make type mistakes ourselves; for
example the example
PaddedIntegerBridge is broken:
public void setParameterValues(Map parameters) {
Object padding = parameters.get( PADDING_PROPERTY );
if (padding != null) this.padding = (Integer) padding; <<< Cast
exception!
}
Cheers,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-7018 and one more change to how we serialize EntityManagerFactory instances...
On 02/08/2012 04:23 AM, Christian Bauer wrote: > (For whatever reason, I still don't understand why EMF clustering would be > different than SF clustering.) This is exactly the point I am missing here as well. -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] ParameterizedBridge API
+1
On Feb 8, 2012, at 5:05 AM, Sanne Grinovero wrote:
> The current API reads:
>
> public interface ParameterizedBridge {
> //TODO inject Properties? since the annotations cannot support Object
> attribute?
> void setParameterValues(Map parameters);
> }
>
> Shall we apply the TODO, or at least change it to specify the expected
> Map types?
>
> public interface ParameterizedBridge {
> void setParameterValues(Map parameters);
> }
>
> Using generics we would keep backwards compatibility.
>
>
> I'm looking at this because we make type mistakes ourselves; for
> example the example
> PaddedIntegerBridge is broken:
>
> public void setParameterValues(Map parameters) {
> Object padding = parameters.get( PADDING_PROPERTY );
> if (padding != null) this.padding = (Integer) padding; <<< Cast
> exception!
> }
>
>
> Cheers,
> Sanne
> ___
> 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
[hibernate-dev] Removing Infinispan dependency on the Hibernate-Infinispan module in 4.x
http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html has more context. Since there are no easy/quick fixes that can be applied at this time, to remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I think we should avoid depending on the service loader way to supply the custom commands (in the Hibernate-Infinispan module), at least until this can be addressed elsewhere. I propose that the Hibernate-Infinispan second level cache should not use the Service Loader to pass custom commands into Infinispan. If we agree, I'll create a jira for this. Scott ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-7018 and one more change to how we serialize EntityManagerFactory instances...
It wouldn't be difficult to switch back to using UUIDs in the EMF. Neither way is perfect (see discussion on HHH-6897). On 02/08/2012 08:28 AM, Steve Ebersole wrote: > On 02/08/2012 04:23 AM, Christian Bauer wrote: >> (For whatever reason, I still don't understand why EMF clustering would be >> different than SF clustering.) > > This is exactly the point I am missing here as well. > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Removing Infinispan dependency on the Hibernate-Infinispan module in 4.x
Scott, what do you suggest doing instead then? Without the commands, evictAll invalidation won't work. Are you suggesting that I revert back to using the cache as a notification bus so that regions are invalidated? On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote: > http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html has > more context. > > Since there are no easy/quick fixes that can be applied at this time, to > remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I > think we should avoid depending on the service loader way to supply the > custom commands (in the Hibernate-Infinispan module), at least until this can > be addressed elsewhere. > > I propose that the Hibernate-Infinispan second level cache should not use the > Service Loader to pass custom commands into Infinispan. If we agree, I'll > create a jira for this. > > Scott -- 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
Re: [hibernate-dev] Removing Infinispan dependency on the Hibernate-Infinispan module in 4.x
On 02/08/2012 10:25 AM, Galder Zamarreño wrote: > Scott, what do you suggest doing instead then? Without the commands, evictAll > invalidation won't work. > > Are you suggesting that I revert back to using the cache as a notification > bus so that regions are invalidated? For the clustered case, is there a way to get the underlying JGroups channel and use that to make remote calls instead of using the cache as a notification bus? > > On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote: > >> http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html >> has more context. >> >> Since there are no easy/quick fixes that can be applied at this time, to >> remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I >> think we should avoid depending on the service loader way to supply the >> custom commands (in the Hibernate-Infinispan module), at least until this >> can be addressed elsewhere. >> >> I propose that the Hibernate-Infinispan second level cache should not use >> the Service Loader to pass custom commands into Infinispan. If we agree, >> I'll create a jira for this. >> >> Scott > > -- > 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
Re: [hibernate-dev] Removing Infinispan dependency on the Hibernate-Infinispan module in 4.x
Btw, I'd rather go with Paul's suggestion to modify AS7 Infinispan subsystem. Also, reverting to the old way of using the cache as a notification bus won't work as is because it relied on using the same cache as for entiies/collections, and it relied on 5.0.x or before logic that caches could be both transactional and non-transactional. So, the only way to deal with this would be to have 1 extra cache per entity/collection to deal with this evictions, which is sucky to say the least… Cheers, On Feb 8, 2012, at 4:25 PM, Galder Zamarreño wrote: > Scott, what do you suggest doing instead then? Without the commands, evictAll > invalidation won't work. > > Are you suggesting that I revert back to using the cache as a notification > bus so that regions are invalidated? > > On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote: > >> http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html >> has more context. >> >> Since there are no easy/quick fixes that can be applied at this time, to >> remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I >> think we should avoid depending on the service loader way to supply the >> custom commands (in the Hibernate-Infinispan module), at least until this >> can be addressed elsewhere. >> >> I propose that the Hibernate-Infinispan second level cache should not use >> the Service Loader to pass custom commands into Infinispan. If we agree, >> I'll create a jira for this. >> >> Scott > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > -- 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
Re: [hibernate-dev] HHH-7018 and one more change to how we serialize EntityManagerFactory instances...
If I understand correctly you are thinking there is a case where the "PU name" would not be unique for a given app? That is the only time I can see this being a concern. If it is possible that the same app can have different PU names on different nodes in the cluster then simply using PU name as EMF name wont work there. But pretty sure I said that this will need to allow explicitly setting of the EMF name. But regardless UUID will never work in a cluster. Thats been covered a few times here. UUID is merely a fallback which assumes ser and deser happen in the same VM. On Wed, Feb 8, 2012 at 9:17 AM, Scott Marlow wrote: > It wouldn't be difficult to switch back to using UUIDs in the EMF. Neither > way is perfect (see discussion on HHH-6897). > > > > On 02/08/2012 08:28 AM, Steve Ebersole wrote: >> >> On 02/08/2012 04:23 AM, Christian Bauer wrote: >>> >>> (For whatever reason, I still don't understand why EMF clustering would >>> be different than SF clustering.) >> >> >> This is exactly the point I am missing here as well. >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-7018 and one more change to how we serialize EntityManagerFactory instances...
I'll set the EntityManagerFactory name to: (1) explicit AvailableSettings.SESSION_FACTORY_NAME if specified (2) use application specified pu-name if pu-name is specified (not always the case, especially in test environments) (3) uuid On 02/08/2012 11:08 AM, Steve Ebersole wrote: > If I understand correctly you are thinking there is a case where the > "PU name" would not be unique for a given app? That is the only time > I can see this being a concern. If it is possible that the same app > can have different PU names on different nodes in the cluster then > simply using PU name as EMF name wont work there. But pretty sure I > said that this will need to allow explicitly setting of the EMF name. > > But regardless UUID will never work in a cluster. Thats been covered > a few times here. UUID is merely a fallback which assumes ser and > deser happen in the same VM. > > On Wed, Feb 8, 2012 at 9:17 AM, Scott Marlow wrote: >> It wouldn't be difficult to switch back to using UUIDs in the EMF. Neither >> way is perfect (see discussion on HHH-6897). >> >> >> >> On 02/08/2012 08:28 AM, Steve Ebersole wrote: >>> >>> On 02/08/2012 04:23 AM, Christian Bauer wrote: (For whatever reason, I still don't understand why EMF clustering would be different than SF clustering.) >>> >>> >>> This is exactly the point I am missing here as well. >>> >> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-7018 and one more change to how we serialize EntityManagerFactory instances...
Ah, nice. I did not even think of reusing SESSION_FACTORY_NAME for the EMF name, but that should work well. On Wed 08 Feb 2012 01:26:30 PM CST, Scott Marlow wrote: > I'll set the EntityManagerFactory name to: > > (1) explicit AvailableSettings.SESSION_FACTORY_NAME if specified > (2) use application specified pu-name if pu-name is specified (not > always the case, especially in test environments) > (3) uuid > > > On 02/08/2012 11:08 AM, Steve Ebersole wrote: >> If I understand correctly you are thinking there is a case where the >> "PU name" would not be unique for a given app? That is the only time >> I can see this being a concern. If it is possible that the same app >> can have different PU names on different nodes in the cluster then >> simply using PU name as EMF name wont work there. But pretty sure I >> said that this will need to allow explicitly setting of the EMF name. >> >> But regardless UUID will never work in a cluster. Thats been covered >> a few times here. UUID is merely a fallback which assumes ser and >> deser happen in the same VM. >> >> On Wed, Feb 8, 2012 at 9:17 AM, Scott Marlow wrote: >>> It wouldn't be difficult to switch back to using UUIDs in the EMF. >>> Neither >>> way is perfect (see discussion on HHH-6897). >>> >>> >>> >>> On 02/08/2012 08:28 AM, Steve Ebersole wrote: On 02/08/2012 04:23 AM, Christian Bauer wrote: > > (For whatever reason, I still don't understand why EMF clustering > would > be different than SF clustering.) This is exactly the point I am missing here as well. >>> > -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate O/RM 4.1.0 and 3.6.10 releases
Both 4.1.0 and 3.6.10 were released today. http://in.relation.to/Bloggers/HibernateORM410Release -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
