The biggest change is in UserType. In the 3.6 branch (i.e., 3.6.2 and
later 3.6.x releases) , the following UserType methods will be deprecated:
public Object nullSafeGet(ResultSet rs, String[] names, Object owner)
public void nullSafeSet(PreparedStatement st, Object value, int index)
A n
2011/2/23 Emmanuel Bernard :
>
> On 23 févr. 2011, at 19:56, Emmanuel Bernard wrote:
>
>>> 1) TimeoutManager should throw specific exceptions directly, depending
>>> on the framework being used
>>> (see the pull request I sent you [1], I think it solves the issue, we
>>> might want to polish it a b
2011/2/23 Emmanuel Bernard :
>
> On 23 févr. 2011, at 19:43, Sanne Grinovero wrote:
>
>> I have to add a third point:
>>
>> Infinispan's Query has a "LazyIterator" functionality, which is really
>> lazy (opposing to
>> Search's scrollable result) it expects the IndexSearcher to not be
>> closed whi
2011/2/23 Emmanuel Bernard :
>
> On 23 févr. 2011, at 18:13, Sanne Grinovero wrote:
>
>> I've been trying to port current work in progress as dependency of
>> Infinispan Query,
>> I'm wishing for these changes:
>>
>> 1) TimeoutManager should throw specific exceptions directly, depending
>> on the f
On 23 févr. 2011, at 19:56, Emmanuel Bernard wrote:
>> 1) TimeoutManager should throw specific exceptions directly, depending
>> on the framework being used
>> (see the pull request I sent you [1], I think it solves the issue, we
>> might want to polish it a bit to have the JPA interface define i
On 23 févr. 2011, at 19:43, Sanne Grinovero wrote:
> I have to add a third point:
>
> Infinispan's Query has a "LazyIterator" functionality, which is really
> lazy (opposing to
> Search's scrollable result) it expects the IndexSearcher to not be
> closed while the user iterates,
> and expects th
On 23 févr. 2011, at 18:13, Sanne Grinovero wrote:
> I've been trying to port current work in progress as dependency of
> Infinispan Query,
> I'm wishing for these changes:
>
> 1) TimeoutManager should throw specific exceptions directly, depending
> on the framework being used
> (see the pull re
I have to add a third point:
Infinispan's Query has a "LazyIterator" functionality, which is really
lazy (opposing to
Search's scrollable result) it expects the IndexSearcher to not be
closed while the user iterates,
and expects the user to close this.
I'm not a big fan for this feature, so for t
I've been trying to port current work in progress as dependency of
Infinispan Query,
I'm wishing for these changes:
1) TimeoutManager should throw specific exceptions directly, depending
on the framework being used
(see the pull request I sent you [1], I think it solves the issue, we
might want to
On Wed, Feb 23, 2011 at 5:19 PM, Sanne Grinovero wrote:
> Hi Marc,
> do you have a link? sorry but "cache + Spring" in google returns a lot
> of crap, most of it quite old.
today's blog entry about spring 3.1
http://j.mp/hACxAM
--
Daniele Dellafiore
http://danieledellafiore.net
___
It kinda like the declarative aspect of it though there are a lot of nasty
strings all around :). The rest is not really new so all old school issues
apply.
As usual for higher level caching you need to manually handle data eviction
which is likely be a source of bugs.
They also don't say if t
On 02/23/2011 04:19 PM, Sanne Grinovero wrote:
> Hi Marc,
> do you have a link? sorry but "cache + Spring" in google returns a lot
> of crap, most of it quite old.
I believe the link is
http://static.springsource.org/spring/docs/3.1.0.M1/spring-framework-reference/html/cache.html
Gustavo
__
I have not looked at the spring code you mention specifically, however caching
entity instances directly as opposed to storing the entity states is never
going to work. Going this route requires that you synchronize access to the
entities in the application since multiple threads/transactions w
Hi Marc,
do you have a link? sorry but "cache + Spring" in google returns a lot
of crap, most of it quite old.
Needless to say, if you cache instances across different sessions /
threads, they will have to be immutable or you will get all kinds of
issues when you make some change, as it would affe
It would be interesting to have the Hibernate team comment/blog on the new
Spring Cache Abstraction functionality and how it relates to Hibernate
managed entities. Perhaps some strategies, etc. It's very attractive to just
cache entities in stead of caching entity values with the second level
cache
15 matches
Mail list logo
