[seek-dev] Questions about implementation of org.kepler.objectmanager.cache.DataCacheObject
Matt Jones
jones at nceas.ucsb.edu
Wed Sep 7 10:02:14 PDT 2005
Hey Chad --
I'm thinking the rewrite of the cache might fall to you as part of the
whole Object Manager work -- you definitely know it the best. Although
certainly Kevin and Jing can pitch in especially with respect to EcoGrid
stuff with DiGIR/Metacat/SRB.
Matt
Chad Berkley wrote:
> Hey Kevin,
>
> There are definitely some weird things going on in that class. I've
> been slowly cleaning it up as i modify it for the object manager. The
> eml200datasource (and any other data sources) are going to need to be
> rewritten to use the object manager anyway, so i think these annoying
> (broken) data source specific methods can just go away or be
> re-architected into the new code. I'm not sure who is slated to re-work
> this code. i think it should probably be either you or jing but i'll
> let matt chime in on that. the object manager is ready for use, so the
> re-write can start now.
>
> chad
>
> Kevin Ruland wrote:
>
>>Hi all,
>>
>>I have some questions about the o.k.objectmanager.cache.DataCacheObject
>>implementation relating to the use of a spin lock in
>>getDataItemFromEcoGrid().
>>
>>The critical facts here are:
>>
>>protected boolean needSynchronize = true;
>>private static boolean lockEcoGrid = false;
>>
>> protected void getDataItemFromEcoGrid(String endPoint, String identifier)
>> {
>>
>> // create a ecogrid client object and get the full record from the
>> // client
>> dbg.print("Get " + identifier + " from " + endPoint, 2);
>> if(needSynchronize)
>> {
>> while(lockEcoGrid)
>> {
>> dbg.print("sleep " + identifier, 2);
>> try
>> {
>> Thread.sleep(500);
>> }
>> catch(Exception e)
>> {
>>
>> }
>> }
>> synchronized(this)
>> {
>> lockEcoGrid = true;
>> }
>>
>> }
>>
>>//*********** Here work is done
>>
>> lockEcoGrid = false;
>> dbg.print("realse lock from " + identifier, 2);
>>
>> }
>>
>>I suspect the intention of the lockEcoGrid flag it to prevent two
>>threads from running the block of code which does actual work. However,
>>the code does not do this. In fact, the spinlock and synchronization
>>code does nothing at all. Certainly the while loop will spin and wait,
>>but the synchronized block does not prevent multiple threads from
>>concurrently operating in the following block. Suppose we have thread
>>1 and thread 2 executing and lockEcoGrid is false. Both threads can
>>fall through to the synchronized statement. Now thread 1 gets to
>>execute the synchronized block, when it's finished, suppose it is
>>suspended. Then thread 2 gets to execute the synchronized block. Now
>>both threads can execute the code in "Here work is done".
>>
>>The only class variable here is lockEcoGrid. So I have to wonder,
>>exactly what is being locked? If some remote resource (ecogrid server)
>>is being locked then this locking should be done in the
>>EcogridFactoryQueryClient class. If this is code held over from a
>>failed attempt to manage the remote resource, then it should be
>>removed. One final consideration is the remote resources can
>>potentially be used by multiple Kepler instances and even two JVMs on
>>the same host do not share synchronization semiphores.
>>
>>Another question I have about this class is why it has a member called
>>"getDataFromEcoGrid()"? Does this really fit with the class' other
>>methods which is about managing a file based cache system? The method
>>is used by both EcogridMetaDataCacheItem, and EcogridDataCacheItem.
>>Perhaps it is better for those two objects to share another ancestor.
>>And finally, EcogridQueryDataCacheItem has almost idential code in its
>>doWork() method so it might benefit from this method as well.
>>
>>Kevin
>>_______________________________________________
>>Seek-dev mailing list
>>Seek-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>
> _______________________________________________
> Seek-dev mailing list
> Seek-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
--
-------------------------------------------------------------------
Matt Jones jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------
More information about the Seek-dev
mailing list