Hi Martin:
I have committed WeakObjectCache based on your email sample code. We
will rename:
- writeLock( key ) to lock( key )
- writeUnlock( key ) to unlock( key )
In order to have a better match ... we will also need to acquire the
lock in the mediator. I am keeping the get and peek methods b
Hi Martin - I just got a chance to look at your code.
First the good news - we are both putting forward the same solution (in
terms of the important two locks in place when writing).
Your code has separated out these concerns into:
-cache: ConcurrentHashMap
-locks: HashMap
Your points are all v
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1296
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
Hi Jesse,
I do think it all comes down to line 20; and what is being locked ...
Regardless we will hook up both implementations, and stress test them -
that way we can measure what is better (and if workers end up piling
up). I only have access to one dual core machine - so we may end up
askin
Pretty picture Jody,
I thought that this conversation wasn't crazy enough so I'm throwing
my understanding into the mix. ;-)
Problem that I see with Martin's solution:
Multiple referencing object cannot be created concurrently because
line 20 acquires the lock on the table. Any other threa
Martin Desruisseaux wrote:
> Sigh... One of us is really not understanding the other one point. I
> claim again that *the read lock in ObjectCacheEntry is totally
> useless* in order to prevent the same CRS to be built twice in two
> different threads. Did you understand the workflow I posted tw
http://geo.openplans.org:9090/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1291
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
Jody Garnett a écrit :
> Hopefully when we provide some stress tests we will be able to better
> communicate the motivation for using two sets of locks.
Sigh... One of us is really not understanding the other one point. I claim
again
that *the read lock in ObjectCacheEntry is totally useless* i
Thanks Martin - we can use this implementation for testing as well. It
looks like it will be a good solution for the non dispatch case.
Hopefully when we provide some stress tests we will be able to better
communicate the motivation for using two sets of locks.
Jody
> Martin Desruisseaux a écrit
Ack so much information! And I volunteered to help write it up ...
Here is the first page:
http://docs.codehaus.org/display/GEOTDOC/01+Use+of+DataSource
And the second:
http://docs.codehaus.org/display/GEOTDOC/02+JDBC+DataStore+Example
I will add to these pages as I understand what Andrea has wr
Andrea Aime ha scritto:
> Hi all,
> I'm about to merge the datasource branch (see connection pooling work)
> so please, no changes until I'm done :)
Ok, I've merged the changes. Please, everybody test this :)
First of all, rebuild your geotools from scratch, and do
a mvn eclipse:eclipse, since ne
Upgrade connection pooling subsystem to DataSource
--
Key: GEOT-1373
URL: http://jira.codehaus.org/browse/GEOT-1373
Project: GeoTools
Issue Type: Improvement
Components: data db2, dat
Thanks for the heads up Andrea :-) And the hard work ... wow this is
pretty amazing. In a couple of months we have gone from a library that
was poorly mannered in a Java EE application to one that can be used :-)
Yeah GeoTools.
Jody
> Hi all,
> I'm about to merge the datasource branch (see conne
Hi all,
I'm about to merge the datasource branch (see connection pooling work)
so please, no changes until I'm done :)
Cheers
Andrea
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of
On 7/4/07, Andrea Aime <[EMAIL PROTECTED]> wrote:
> Justin Deoliveira ha scritto:
> > Hello all,
> >
> > Below you will find the two alternate plans I have come up with regard
> > to the api changes needed for the 2.4 feature model. Can each of those
> > interested who provided feedback (currently
make feature model api changes for 2.4 branch
-
Key: GEOT-1372
URL: http://jira.codehaus.org/browse/GEOT-1372
Project: GeoTools
Issue Type: Bug
Reporter: Justin Deoliveira
A
Justin Deoliveira ha scritto:
> Hello all,
>
> Below you will find the two alternate plans I have come up with regard
> to the api changes needed for the 2.4 feature model. Can each of those
> interested who provided feedback (currently Andrea,Jody,and Martin)
> please vote on the option which the
Martin Desruisseaux a écrit :
So there is my proposal: I will commit a ObjectCache2 class (without any
ObjectCacheEntry class) so you can see my point. It will use the modified
workflow that I tried to explain in my previous email.
There is the proposal (not commited because it use Java 5 feat
Hey all,
Since we are discussing the road map, let's aim for an elegant version
numbering scheme which helps our users understand our library and its
history. I propose we release:
2.4.x => Java 1.4 & simple features
Aiming for stability and bug fixing only.
I'm of course +1 for switching to Java 5 for Geotools 2.5 :)
As of Geotools 2.4, it would be a little bit unfortunate to switch it to Java 5
so close to the release date after the effort we did for keeping it Java 1.4
compliant...
Martin
Cory Horner a écrit :
> With a single write lock for the whole map, we would be constrained to
> create a single object at a time, thus making our worker strategy less
> than effective.
Again I agree and already understood that, but the "only write lock" discussion
was for ObjectCacheEntry, not
Jody Garnett a écrit :
> Martin could you let us know when (and it does not need to be soon) you
> would like to review our referencing work. We will need to know at least
> a week in advance for planning, The time frame for GeoTools 2.4 and
> scheduling needs to be acceptable to everyone after
22 matches
Mail list logo
