Aaron, Just a quick note... overriding JDBCDiskCache.getCacheType() seems to be working well for us so far. Thanks again for the input. I will let you know if I run into any unexpected features.
Randy On Fri, 2006-11-03 at 11:20 -0700, Randy Watler wrote: > Aaron, > > Cool. I was going to try this out today after reviewing the > ramifications in the code of claiming the JDBCDiskCache was remote. It > is encouraging to hear that you think this might work as well! > > Thanks for the continued feedback. > > Randy > > On Fri, 2006-11-03 at 09:11 -0800, Aaron Smuts wrote: > > You could of course, create a wrapper for the jdbc > > disk cache that returned the remote type. Just extend > > it and override that method. That would be a hack, > > but it's easy since JCS is pluggable. > > > > --- Aaron Smuts <[EMAIL PROTECTED]> wrote: > > > > > 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 > > > cache. > > > > > > Cheers, > > > > > > Aaron > > > > > > > > > --- Randy Watler <[EMAIL PROTECTED]> 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: > > > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
