jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject Re: JDBCDiskCache as Remote Cache
Date Fri, 03 Nov 2006 16:57:16 GMT
The remote cache doesn't work the way you described
exactly.  If a remove request goes to the remote
server, it sends it to all listeners and to all
auxiliaries.  There is no command to remove from
memory only.  

Just like the lateral cache, it can be configured to
send remove requests.  If you have the lateral client
configured to get from the other laterals, then the
laterals start to look like a bunch of remote caches. 
However, this is not advisable when  you have a buch
of machines.  You don't want to have to search 50
boxes for every cache miss. . . . .  

If you are using a shared jdbc disk cache, then there
is no reason not to use the remote server.  I push
over 500 puts a second through a remote cluster and do
the same number of gets . . .  If you are worried
about memory, then configure the remote server to not
store very much or anything in memory.  That's how I
use it for most regions.  Use the remote cache as a
way to access the JDBC disk cache.  Also, the remote
will take care of the invalidation messages for you. 
It is the most scallable way to go.  Also, you can
partition the data into multiple rmeote clusters in
the future if you needed to scale.   . . .

Hmmn.  I see what you are trying to do.  If the disk
cache was configured as a non-local auxiliary (i.e.
remote or lateral) then yes, the remove would not
remove the item from disk.  What we need is a new type
called shared or remote disk.  This would do the
trick.        The assumption that all disk caches are
local is false in this case.  Perhaps we could use the
disk mode setting.   . . . Let me think about it a bit
more.  For now, I suggest that you use the remote



--- Randy Watler <watler@wispertel.net> wrote:

> We are attempting to use a JDBCDiskCache in a shared
> mode with multiple
> cache clients using it as their backing store. We
> are also interested in
> using the TCPLateralCache in "remove on put" mode to
> help keep the
> clients roughly in sync where their extents overlap,
> (albeit not at a
> transactional level). We are not using a remote
> cache because each cache
> client will have a largely orthogonal working set in
> relation to the
> other clients and that would force the single remote
> cache to hold a
> very large working set for no advantage.
> Conceptually speaking, we are
> attempting to use the JDBCDiskCache as a remote
> cache instead.
> Therein lies a problem though. Because the
> JDBCDiskCache is in fact a
> disk cache, JCS propagates lateral updates as
> removes to this auxiliary
> cache. This ends up actually removing the elements
> from the
> JDBCDiskCache instead of simply removing the items
> from the memory cache
> as would happen if it were a remote cache.
> I am wondering if it would be reasonable to allow a
> JDBCDiskCache to
> masquerade as a remote cache by indicating that its
> cache type is
> remote? This would seemingly allow the cache to
> operate as a "remote"
> disk cache. True?
> Any comments/tips would be appreciated. Thanks,
> Randy
> To unsubscribe, e-mail:
> jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org

To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org

View raw message