> -----Original Message-----
> From: James Taylor [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 14, 2002 2:56 PM
> To: Turbine JCS Developers List
> Subject: RE: cvs commit: jakarta-turbine-jcs/src/test/org/apache/jcs TestD
> iskCache.java
>
> On Tue, 2002-05-14 at 14:23, Aaron Smuts wrote:
> > Hmmn. I think it has always been a bit funny.
>
> =]
>
> All the old stuff is still under the stratum repository, in the Attic.
Ya, I was looking at it.
>
> > We may have to update the item in purgatory as not spoolable, then
> remove it
> > so the element in the queue will no longer be sppolable.
>
> I'm changing 'remove' so that it gets the element and sets it to be not
> spoolable.
>
Sounds good. The put will stop.
> > What if it is writing at that moment?
>
> I think we need to be able to synchronize remove and put. We could share
> a lock with the event queue. Basically in remove we would say 'finish
> whatever the current event is and then pause' to the queue, execute the
> removal, and the resume the queue. I think that is the only safe way to
> synchronize the two. Shouldn't be that hard!
>
That queue is generic. You can keep the locking in the disk cache. You
should be able to use the read write lock manager and lock on the region and
key name or something in the doUpdate and doRemove methods. This would
assure that the spoolable flag can be change in time.
> > Perhaps the put event should get the item from purgatory prior to
> writing to
> > disk.
> >
> > So on put we put into a purgatory wrapper and then create a put event.
> >
> > When the put event runs it could get the item from purgatory first, make
> > sure it is spoolable and then put.
>
> Doesn't it already do this?
>
> > On remove we remove from purgatory and disk.
>
>
>
> --
> To unsubscribe, e-mail: <mailto:turbine-jcs-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:turbine-jcs-dev-
> [EMAIL PROTECTED]>
