Re: [hibernate-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Galder Zamarreno]

Resending to hibernate-dev list.

On 08/04/2009 10:37 AM, 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...
>
> 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,

-- 
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] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Manik Surtani]

On 4 Aug 2009, at 09:37, 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


hibernate.cache.infinispan.cfg ?

- why do we need 'region' in there, non-intuitive to end-users?
- I'd rather use infinispan rather than ispn.



2. Need a equivalent version of this region factory where cache  
manager

is retrieved from JNDI. Suggsted property name:
hibernate.cache.region.ispn4.manager


s/region.ispn4/infinispan



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


s/region.ispn4/infinispan



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



s/region.ispn4/infinispan


6. Add more unit tests!

7. Document in wiki.


Good stuff, thanks for taking this on!
- Manik



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...

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,
--
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




___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Spliting Lucene segments in Infinispan Directory

[Emmanuel Bernard]

Manik,
do you have some insight? We can't really understand why this is split.

Emmanuel

On  Jul 30, 2009, at 19:51, Łukasz Moreń wrote:

> Hi,
>
> The JBoss Cache directory for Lucene splits each Lucene segment into  
> pieces - chunks. Similar solutions exists in Lucene RamDirectory  
> implementation.
> Are there some pros to use such splitting approach in Infinispan  
> directory case? Some buffer size is recommended?
>
> Lukasz
> ___
> 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] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Galder Zamarreno]

On 08/04/2009 11:32 AM, Manik Surtani wrote:
>
> On 4 Aug 2009, at 09:37, 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
>
> hibernate.cache.infinispan.cfg ?
>
> - why do we need 'region' in there, non-intuitive to end-users?
> - I'd rather use infinispan rather than ispn.

Ok, fair enough.

>
>>
>> 2. Need a equivalent version of this region factory where cache manager
>> is retrieved from JNDI. Suggsted property name:
>> hibernate.cache.region.ispn4.manager
>
> s/region.ispn4/infinispan

Ok

>
>>
>> 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
>
> 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.

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.

>
>>
>> 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
>>
>
> s/region.ispn4/infinispan

Ok.

>
>> 6. Add more unit tests!
>>
>> 7. Document in wiki.
>
> Good stuff, thanks for taking this on!

You're welcome :)

> - Manik
>
>>
>> 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...
>>
>> 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,
>> --
>> 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
>
>
>
>
>

-- 
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] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Manik Surtani]

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.


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.


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?

Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org




___
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

[Steve Ebersole]

On Tue, 2009-08-04 at 14:35 +0100, Manik Surtani wrote:

Yes this is obviously something worthwhile at a high level.  I cannot
speak to implementation details wrt Infinispan.

> 
> 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.  
> 
-- 
Steve Ebersole 
Hibernate.org

___
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

[Brian Stansberry]

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: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Brian Stansberry]

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 
> 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

[Galder Zamarreno]

On 08/04/2009 03:35 PM, 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.
>>
>> 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.
>
> 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.

That's already doable. I mean, you can have a named cache with the FQCN 
of the class and that means that when a region for that entity is 
created, it will pick the named cache with the specific eviction policies.

>
> Brian/Steve - care to chime in?
>
> Cheers
> --
> Manik Surtani
> ma...@jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>

-- 
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] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Brian Stansberry]

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 
>> 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

[Galder Zamarreno]

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?

>
 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.

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.

>>
>> 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 
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>>
>>>
>>>
>>>
>>
>>
>
>

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
__

Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Galder Zamarreno]

On 08/04/2009 06:23 PM, Brian Stansberry wrote:

> 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.
>

+1

-- 
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] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Galder Zamarreno]

On 08/04/2009 05:53 PM, Brian Stansberry wrote:
> 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.

Different entities can indeed have different eviction settings as 
mentioned in another email. My reference to evictions above was merely 
about the FQNs leading to entities...etc.

>
> 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,
>
>

-- 
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] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Brian Stansberry]

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 what I described 
below implemented already?

> 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. 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", 

[hibernate-dev] Fwd: [jsr-303-eg] [NEW] SecurityManager considerations

[Emmanuel Bernard]

Begin forwarded message:


From: Emmanuel Bernard 
Date:  August 4, 2009 16:26:57  EDT
To: jsr-303...@jcp.org
Subject: Re: [jsr-303-eg] [NEW] SecurityManager considerations
Reply-To: jsr-303...@jcp.org


On  Aug 4, 2009, at 12:57, Ed Burns wrote:

On Thu, 16 Jul 2009 14:19:49 -0700, Ed Burns  
 said:


On Wed, 15 Jul 2009 08:21:06 -0400, Emmanuel Bernard > said:

EB> Is there other specs enforcing that. I know JPA does not, I am
EB> wondering if other pluggable EE specs enforce such calls.

EB> I'll ask around and report back.

EB> Other question, what's the perf cost?

EB> At the same time as discussing runtime performance cost, we  
also need to

EB> agree on how strongly we want to require it.  My original wording
EB> started with, "If the implementation is intended to run in a  
container

EB> with the SecurityManager enabled..." meaning that compliance is
EB> optional.  I think we should stick with that level of compliance.

EB> As for runtime performance, I'll ask our expert but I think the  
general
EB> practice is to use the doPrivledeged() versions only if  
actually running

EB> with SecurityManager enabled.

Here's what Ron Monzillo had to say when asked this question.

On Fri, 17 Jul 2009 10:28:37 -0400, Ron Monzillo > said:


RM> Ed, as I said, he should only wrap those apis, that having done  
so,
RM> woould not be such that they would then provided their callers  
with an
RM> opportunity to exploit the java security model. Iow, he doesn't  
want his
RM> api to be the manifestation of a capability that can be used by  
its
RM> callers to do things that they would otherwise be prevented (by  
the

RM> security managr from doing) from doing.

RM> within that context, which I admit is pretty high level,  the  
answer to
RM> his question afaik, is no, in other words I don't know of any  
places

RM> where we have mandated such encapsulation... but you can turn the
RM> question around, or at least reinforce what you have already  
said,

RM> perhaps by saying (somthing like)

RM> if he doesn't do the encapsulation within his api, he is in  
establishing

RM> a requirement that the java protection model be disabled for any
RM> application that needs to call his api; which as you hav noted
RM> substantially limits the potential utility of running with a  
security

RM> manager enabled.

Please let me know if you need more information.


Here is my analysis.
The RI does need to priviledge the following calls:
- Thread.getContextClassLoader()
- Class.getClassLoader()
- Class.getMethods()
- Class.newInstance()
- Class.getMethod(String)
- Class.getConstructor()
- Class.getDeclaredFields()
- Class.getDeclaredMethods()
- Class.getDeclaredField(String) / getDeclaredMethod(String)
- AccessibleObject.setAccessible

The RI might need to priviledge the following calls:
- method.invoke
- Field.get

Now here are the gotchas.
Bean Validation does expose some of the result of these methods  
(indirectly).
- ConstraintViolation.getInvalidValue does expose the value and a  
few of the priviledged info (property path, leafBean etc)
- the metadata API does expose property names (and their return  
type): there are the names of potentially non public field or getters


Do we consider the exposition of these extra info as breaking the  
doPriviledge contract. As Ron was saying we are giving away some  
information that a non privileged code could not have access to  
otherwise.


So we have two choices, consider that if the user does not have  
access to these priviledges, we fail as well (the current impl).
Make use of our priviledged position but be aware of the leaks we  
enable.

WDYallThink?


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev