Glad to see that Matthew is going to pursue some technology assessment and provide one or more suggestions to providing a caching layer. See below for inline comments.
James ----- Original Message ----- From: "Ned Wolpert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 01, 2001 11:39 AM Subject: Re: [castor-dev] Performance > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The more I think of it, having a generic interface to the caching technique does > make sense. If there is some factory method that retrieves the current caching > classes, people (and companies) can write their own caching system to add to Right, I would offer a pluggable caching layer. In essence, caching should be invisible but known to the application developer. The architect should know how/where to optimize, and be able to choose the caching mechanism appropriate for the project, as well as the appropriate configurations for it, from the list of existing caching mechanisms. > the mix. This would help the future addition of a distributed cache, even if > its not ready now. The caching classes could be variables in the database.xml > file, which are loaded when the database is created. > Might I suggest the service-style factory (ala JAXP + pluggable jar) for pluggable cache implementations? Having it defined in the database.xml *could* cause problems if multiple database.xml files are used throughout a single application (read VM). This may not be an issue with Castor if the cache is on a per-database basis, but I thought I'd mention using a more Java-esque form of factory management. > On 28-Sep-2001 Thomas Yip wrote: > > Can you give me more detail on what are you going to do? > > > > On the other hand, I have been think should I abandon the generic interface, > > and restrict to the cache object to ObjectLock. And, add double link to > > ObjectLock, so that the implementation can optimize a little bit. > > > Virtually, > Ned Wolpert <[EMAIL PROTECTED]> > > D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE7uJwsiysnOdCML0URAmo/AJ4qTjdc7DtbDrVdufMwi9BR5E8jpACfUx16 > 1VKC0obCMudwYe6gp6yVf/E= > =uzh6 > -----END PGP SIGNATURE----- > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
