Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airavata.apache.org
Received-SPF: pass (athena.apache.org: domain of glahiru@gmail.com designates
 209.85.212.177 as permitted sender)
MIME-Version: 1.0
Date: Tue, 27 May 2014 12:04:33 -0400
Message-ID: 
 <CAKq9_6J81Gzw9+PGvihNt6H9UosjNR0SVvEsDB9z7wDTvSCWVQ@mail.gmail.com>
Subject: Implementing a cache registry
From: Lahiru Gunathilake <glahiru@gmail.com>
To: dev <dev@airavata.apache.org>
Content-Type: multipart/alternative; boundary=047d7bb04fee0fdfb804fa63da64

--047d7bb04fee0fdfb804fa63da64
Content-Type: text/plain; charset=UTF-8

Hi Devs,

In our current implementation we have large number of Experiment retrieval
and experiment storing happen in between experiment creation and experiment
completion. We do not really parse these data-model objects between
component and we simply parse the ids of these experiment so every
component has to retrieve them everytime. I think programatically this
approach looks much cleaner than parsing big objects. But to make this more
efficient we can use a cachedRegistry implementation as another
implementation of registry and make sure we do not get objects all the way
from the database.

Each component can init its own cache registry object and it will build a
cache on that module and update the cache if some other component had
changed the data-model objects. IMHO if we implement a good caching layer
on our current data-model airavata registry will be more efficient.

WDYT ?

Regards
Lahiru

-- 
System Analyst Programmer
PTI Lab
Indiana University

--047d7bb04fee0fdfb804fa63da64
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Devs,<div><br></div><div>In our current implementation =
we have large number of Experiment retrieval and experiment storing happen =
in between experiment creation and experiment completion. We do not really =
parse these data-model objects between component and we simply parse the id=
s of these experiment so every component has to retrieve them everytime. I =
think programatically this approach looks much cleaner than parsing big obj=
ects. But to make this more efficient we can use a cachedRegistry implement=
ation as another implementation of registry and make sure we do not get obj=
ects all the way from the database.=C2=A0</div>
<div><br></div><div>Each component can init its own cache registry object a=
nd it will build a cache on that module and update the cache if some other =
component had changed the data-model objects. IMHO if we implement a good c=
aching layer on our current data-model airavata registry will be more effic=
ient.</div>
<div><br></div><div>WDYT ?</div><div><br></div><div>Regards</div><div>Lahir=
u<br clear=3D"all"><div><br></div>-- <br>System Analyst Programmer<div>PTI =
Lab</div><div>Indiana University</div>
</div></div>

--047d7bb04fee0fdfb804fa63da64--