Cache Loaders and Non-String Fqns - Was: 2.0.0.BETA2
by Manik Surtani
On 15 Mar 2007, at 18:24, Brian Stansberry wrote:
> Manik Surtani wrote:
>> I think we're going to need to support non-String Fqns. We're not
>> going away from that anytime soon. :S
>
> Good. I'm not positive, but I think the only place non-String Fqns
> are irreparably broken is with a preload call to a cache loader.
Well, any config file element that uses Fqns. Eviction policies, for
example. But that's a limitation on the config file, nothing else.
> With other cache loader calls, the real fqn is available as a call
> parameter, so the string-based representation used for the
> persistent store doesn't have to leave the cache loader.
Yeah, that can be worked around. What do you reckon the best
approach for "encoding" Fqns are, for CLs that only use Strings?
For each Fqn element, "Type:" + element.getClass() + ":value:" +
element.toString() ?
Could barf with user objects that don't override toString() and you
have object hash codes...
CC'ing dev list, BTW.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 9 months
'old' and 'tests-50' dirs in JBoss Cache HEAD
by Manik Surtani
Ben,
These contain some legacy pojocache stuff. Can these be removed? I
presume this has been integrated into the src and tests dirs?
I'd like to do this before BETA2, by the end of this week.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 9 months
Hibernate, JBoss Cache and transactions
by Manik Surtani
Hi,
Looking at this forum thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028373
I see an issue with the cache.remove() call being made in the
afterCompletion() block of a Synchronization. The main issue here is
that the current transaction is no longer valid by this stage (it
has, by definition, completed). From a transactional sense, what is
the purpose of remove() being called in an afterCompletion() block?
Is it intended that this remove() happens outside of the current
transaction (either in a new transaction or without one)?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 9 months