- Original Message -
> From: "David M. Lloyd"
> To: "infinispan -Dev List"
> Cc: hibernate-dev@lists.jboss.org, "jboss-as7-...@lists.jboss.org
> Development" ,
> "Galder Zamarreño"
> Sent: Tuesday, March 6, 2012 2:55:18 PM
> Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing
larClassResolver to marshal/unmarshal
session objects.
> >
> > On Mar 6, 2012, at 8:19 PM, Galder Zamarreño wrote:
> >
> >>
> >> On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
> >>
> >>> On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
&
arreño wrote:
>
> >
> > On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
> >
> >> On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
> >>> On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
> >>>
> >>>> To work around this,
- Original Message -
> From: "Galder Zamarreño"
> To: "Paul Ferraro"
> Cc: "Jason T. Greene" , "Bela Ban"
> , "infinispan -Dev List"
> , hibernate-dev@lists.jboss.org,
> "jboss-as7-...@lists.jboss.org Dev
- Original Message -
> From: "Jason T. Greene"
> To: "David M. Lloyd"
> Cc: "Galder Zamarreño" , "Paul Ferraro"
> , "Bela Ban" ,
> "infinispan -Dev List" ,
> hibernate-dev@lists.jboss.org,
> "
On Tue, 2011-08-16 at 10:45 -0400, Scott Marlow wrote:
> On 08/16/2011 10:26 AM, Sanne Grinovero wrote:
> > Hi Scott,
> > demanding people to configure a new cache for each application is very
> > tricky because of ISPN-658, unless you're referring to creating a
> > whole new instance of Infinispan
On Tue, 2010-11-16 at 17:25 +, Sanne Grinovero wrote:
> Hi,
> I see that the Infinispan second level cache defines a nice property
> "hibernate.cache.infinispan.cachemanager" to search an existing
> CacheManager via JNDI.
>
> Now in case of Hibernate Search's DirectoryProvider making use of
>
Hi,
Could someone look at HHH-4441 and comment on the patch attached in
jira?
I'm working on an optimization for ejb3 stateful session bean
replication in jboss, and HHH-4441 prevents me from leveraging JBoss
Marshalling for entity manager serialization.
Paul
LC 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(...)).
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
10 matches
Mail list logo
