Re: Making Velocity truly concurent

Jan,

On 9/28/12 3:15 PM, Jan Algermissen wrote:
> 
> On Sep 28, 2012, at 8:36 PM, Christopher Schultz wrote:
> 
>> Jan,
>>
>> On 9/21/12 2:45 AM, Jan Algermissen wrote:
>>> looking at the code yesterday, I saw that Velocity uses a number of
>>> Serialized classes (e.g. the SerializedMap in ResourceCache).
>>>
>>> I would like to replace all relevant classes to avoid serialization
>>> completely.
>>
>> Do you mean avoid all /synchronization/?
> 
> Yes, because I am in Java EE6 container and have a request scoped Velocity
> context. In my understanding the only hot spot is the template cache and a
> concurrent Map would solve that, correct?

If you have a request-scoped Velocity (meaning that each request gets
its own Velocity object), then you can certainly create separate
resource loaders, etc. and have zero contention at all. Un-contended
lock acquisition is very cheap these days.

>>> Are concurrent versions of these classes available already?
>>
>> You mean something like java.util.concurrent?
> 
> Yes. I would basically replace the SynchronizedMap with a ConcurrentHashMap.
> Before I do that, I was wondering whether anyone has done that already.
> 
> ... and whether it would work, of course :-)

Since you have studied things in-depth, what do you think? Could
SynchronizedMap be directly-replaced by ConcurrentHashMap? I think it
would be better to use an API-provided class than to use a hand-rolled
one from Velocity.

-chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBpsP8ACgkQ9CaO5/Lv0PDDWwCgrGiZTnoyd2AbVPpYuVLsTwqy
9K0AnjndSkHqauS40xvVD1qXVZBaMfFH
=hGT3
-----END PGP SIGNATURE-----