Object creation/locking issue

Wed, 18 Feb 2004 08:40:40 -0600

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3F62D.2E58D504
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I'd like to ask about the feasibility of a couple of things, including
blocking and cache reuse strategy. 

1. Requirement for blocking on access to a key: 

Here is a scenario -- taking usage out of the pure web-interface
implementation: 

Supposing I wish to cache objects that are computationally expensive to
generate, ie to the order of a few seconds up to 15 minutes.  I can have
unique keys, put them in namespaces, and otherwise identify them, but I
really do not want to be generating them in parallel, as that chews up
resources.

So, if a process discovers that the object is not in the cache, it needs
to 'lock' that key before going off to generate the object, so that any
other process looking up that object are blocked until it has been put
in to the cache.  Clearly, the block would have to be dropped if that
other process dies (or unlocks the key) without generating the object.

2. Caching on mfu, creation expense and time 

Having a cache capacity limit that drops objects based on their
popularity as well as age would be a strong advantage when there are
limited memory resources for caching, or under-utilised objects are
stored.  Better still, storing a 'construction expense' value with an
object would permit relatively cheap objects to be purged in order to
maintain the most expensive cache elements longer.

As it stands, I can't see memcache catering to either of these
requirements - is it planned for the future, or is this just not the
tool for the job?

Regards, 
Tom 

------------------------------------------------------------------------
---------------------

The information contained in this transmission and any attached
documents is privileged, confidential and intended only for the use of
the individual or entity named above. If the reader of this message is
not the intended recipient, you are hereby directed not to read the
contents of this transmission, and are hereby notified that any
disclosure, copying, distribution, dissemination or use of the contents
of this transmission, including any attachments, or the taking of any
action in reliance thereon, is strictly prohibited. If you have received
this communication in error, please notify the sender and/or Citadel
Investment Group (Europe) Ltd immediately by telephone at +44 (0) 20
7645 9700 and destroy any copy of this transmission.

Citadel Investment Group (Europe) Ltd is authorised and regulated by the
Financial Services Authority (FSA Firm Ref No 190260).
Registered in England. Registration No. 3666898.
Registered Office: 10th Floor, 2 George Yard, Lombard Street, London
EC3V 9DH

------_=_NextPart_001_01C3F62D.2E58D504
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6389.0">
<TITLE>Object creation/locking issue</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">I'd like to ask about the feasibility =
of a couple of things, including blocking and cache reuse =
strategy.</FONT>
</P>
<BR>

1. Requirement for blocking on access =
to a key:

<P><FONT SIZE=3D2 FACE=3D"Arial">Here is a scenario -- taking usage out =
of the pure web-interface implementation:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Supposing I wish to cache objects that =
are computationally expensive to generate, ie to the order of a few =
seconds up to 15 minutes.&nbsp; I can have unique keys, put them in =
namespaces, and otherwise identify them, but I really do not want to be =
generating them in parallel, as that chews up =
resources&#8230;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So, if a process discovers that the =
object is not in the cache, it needs to 'lock' that key before going off =
to generate the object, so that any other process looking up that object =
are blocked until it has been put in to the cache.&nbsp; Clearly, the =
block would have to be dropped if that other process dies (or unlocks =
the key) without generating the object&#8230;</FONT></P>
<BR>

2. Caching on mfu, creation expense and =
time

<P><FONT SIZE=3D2 FACE=3D"Arial">Having a cache capacity limit that =
drops objects based on their popularity as well as age would be a strong =
advantage when there are limited memory resources for caching, or =
under-utilised objects are stored.&nbsp; Better still, storing a =
'construction expense' value with an object would permit relatively =
cheap objects to be purged in order to maintain the most expensive cache =
elements longer.</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">As it stands, I can't see memcache =
catering to either of these requirements - is it planned for the future, =
or is this just not the tool for the job?</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Tom</FONT>
</P>

<br>
<br>
<br>
<br>
-------------------------------------------------------------------------=
--------------------<br>
<br>
The information contained in this transmission and any attached =
documents is privileged, confidential and intended only for the use of =
the individual or entity named above.  If the reader of this message is =
not the intended recipient, you are hereby directed not to read the =
contents of this transmission, and are hereby notified that any =
disclosure, copying, distribution, dissemination or use of the contents =
of this transmission, including any attachments, or the taking of any =
action in reliance thereon, is strictly prohibited.  If you have =
received this communication in error, please notify the sender and/or =
Citadel Investment Group (Europe) Ltd immediately by telephone at +44 =
(0) 20 7645 9700 and destroy any copy of this transmission.<br>
<br>
Citadel Investment Group (Europe) Ltd is authorised and regulated by the =
Financial Services Authority (FSA Firm Ref No 190260).<br>
Registered in England.  Registration No. 3666898.<br>
Registered Office:  10th Floor, 2 George Yard, Lombard Street, London =
EC3V 9DH<br>
</BODY>
</HTML>
------_=_NextPart_001_01C3F62D.2E58D504--