[jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-25 Thread Thomas Vandahl
Hi Romain, On 24.05.14 20:16, Romain Manni-Bucau wrote: > basically I respected all remarks, only pendings ones are: > > 1) modules Ok, right now, I see the following modules - commons-jcs-core - commons-jcs-jcache - commons-jcs-jcache-extras - commons-jcs-jcache-openjpa - commons-jcs-tck-tests

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-25 Thread Romain Manni-Bucau
Responses inline. 2014-05-25 15:03 GMT+02:00 Thomas Vandahl : > Hi Romain, > > On 24.05.14 20:16, Romain Manni-Bucau wrote: > > basically I respected all remarks, only pendings ones are: > > > > 1) modules > > Ok, right now, I see the following modules > - commons-jcs-core > - commons-jcs-jcache

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-25 Thread Phil Steitz
On 5/25/14, 8:18 AM, Romain Manni-Bucau wrote: > Responses inline. > > > 2014-05-25 15:03 GMT+02:00 Thomas Vandahl : > >> Hi Romain, >> >> On 24.05.14 20:16, Romain Manni-Bucau wrote: >>> basically I respected all remarks, only pendings ones are: >>> >>> 1) modules >> Ok, right now, I see the follo

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-26 Thread Thomas Vandahl
On 25.05.14 17:18, Romain Manni-Bucau wrote: > Extras is a set of useful basic classes for JCache usage. OpenJPA is JCache > support for L2 cache in openjpa. > > The goal is to make what we propose with jcache module as usable as > possible and avoid glue code as much as possible in application co

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-26 Thread Thomas Vandahl
On 25.05.14 17:45, Phil Steitz wrote: > On 5/25/14, 8:18 AM, Romain Manni-Bucau wrote: >>> And please consider reacting to Phils comment on the removal of >>> synchronized keywords. It took years to pinpoint the race issues in the >>> JCS code. I don't claim the current situation to be perfect but

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-26 Thread Romain Manni-Bucau
the point is putIfAbsent is costly but globally once (can be done concurrently but this is ignorable at runtime). Only important thing is to ensure then the system uses a single instance. Issue with sychronized is that it doesn't scale. If you go upper to 10 threads you are slow. The other point

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-27 Thread Thomas Vandahl
On 26.05.14 22:05, Romain Manni-Bucau wrote: > the point is putIfAbsent is costly but globally once (can be done > concurrently but this is ignorable at runtime). Only important thing is to > ensure then the system uses a single instance. Right, but what if the instance creates a file, socket or s

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-28 Thread Romain Manni-Bucau
2014-05-27 21:13 GMT+02:00 Thomas Vandahl : > On 26.05.14 22:05, Romain Manni-Bucau wrote: > > the point is putIfAbsent is costly but globally once (can be done > > concurrently but this is ignorable at runtime). Only important thing is > to > > ensure then the system uses a single instance. > > R

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-28 Thread Romain Manni-Bucau
Found an IBM article showing globally what I experimented: http://www.ibm.com/developerworks/java/library/j-jtp10264/ So I'll first add ReentrantLock where synchronized was used, then bench it again and see depending performances if we need the LockFactory abstraction or not. Does it work for you