Just a thought: If the potential of adding distributed caching is in the future of Castor or at least needs to be supported along with cache eviction, maybe a basic whitepaper describing the approach(es) available, compare/contrast the existing solutions from TopLink, CocoBase, and others, should be written? This can determine the right way of providing hooks to an SPI rather than an open API or another solution for offering caching control and distributed cache capabilities.
I know that TopLink didn't offer much in the way of cache flushing without some work in v2, not sure about v3 or beyond. I do know that they offered a distributed cache SPI in v2 and maybe even a basic impl in v2 or 3. CocoBase was pretty simple last time I saw it, and I'm sure other solutions are out there. A whitepaper overviewing each available solution and the best fit for Castor would ensure all needs described in these threads are satisfied in a way that doesn't compromise Castor's safe and effective APIs. James ----- Original Message ----- From: "Thomas Yip" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 28, 2001 6:46 PM Subject: Re: [castor-dev] Performance > 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. > > > Thomas > > -----Original Message----- > >From: Adam Esterline [mailto:[EMAIL PROTECTED]] > >Sent: Friday, September 28, 2001 4:34 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Performance > > > >RE: [castor-dev] PerformanceI have asked to improve the Cache > >implementation. I think that there are several of us who would be willing > >to discuss how we can improve the cache. (ie. Changing LRU.java to a more > >generic Cache.java, allowing the user to create their own cache types....) > > > >Adam > > > >----- Original Message ----- > >From: Thomas Yip > >To: [EMAIL PROTECTED] > >Sent: Friday, September 28, 2001 5:41 PM > >Subject: Re: [castor-dev] Performance > > > > > >I am not convinced that Castor JDO is ready for distributed cache yet. > >Having a distributed cache may not solve the problem you want to solve. > >Well, we're moving to that direction. > > > > > >In fact, Castor's LockEngine have two levels. The lock level keeps all ROWs > >in action. The access to a ROW in the lock level is guarded by read/write > >lock, the value should not be changed, even in case of cache invalidation > of > >that particular ROW. Because, the value is used for modification detection > >in later time. So, eviction should not be done on any locked object. But, > it > >should be flagged instead, so in the commit of rollback time, the > LockEngine > >can decide what to do. > > > > > >Not until the transaction is completed and no other transaction interested > >in that particular ROW, it is moved to the cache level. On the other hand, > >the make sure a particular ROW would only exist zero or one time in the > lock > >level and the cache level, the adding/removing/moving of ROW is > synchronized > >between the cache level and lock level. Because of that, the eviction > should > >not be implemented outside the LockEngine. Consider the current > >architecture, the active cache in JCACHE or distributed cache might not be > >the best fit. > > > > > >Also, when a ROW is invalidated, in some case, the related ROW should be > >done too. And, it is not easy in the current implementation. > > > > > >If Castor JDO is a house, we are taking off walls in order to extend the > >house. At this moment, I rather wait until some extensions to finish first, > >before starts discussing and planning the next walls to be taken off. > >However, I am open to discuss building furniture that does not involve > >taking wall off. > > > > > >Examples of furniture are other passive cache types: weakReference cache, > >time-count limited cache or speedier implementation etc. > > > > > > > >Thomas > > > > > > > > > > > > > >-----Original Message----- > >From: Adam Esterline [mailto:[EMAIL PROTECTED]] > >Sent: Friday, September 28, 2001 12:12 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Performance > > > >I would. I have offered to clean up the current cache implementation. > > > >Adam > >-----Original Message----- > >From: Matthew Baird [mailto:[EMAIL PROTECTED]] > >Sent: Friday, September 28, 2001 2:09 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Performance > >the solution, imho, is a distributed cache. THere is a JCP in process with > >oracle for this kinda of technology. > > > >A stopgap would be to have an evict function and keep caches in sync with a > >pubsub jms implementation, but this doesn't solve the issue of updates in a > >highly distributed transactional system. > > > >Setting the caching to NONE is not an issue for those of us using castor in > >a j2ee environemnt (probably more and more of us every day). And setting > the > >cache countlimited isn't a real solution for obvious reasons. > > > >If a distributed cache for castor project was started, who would be > >interested in helping? > >-----Original Message----- > >From: Sudhir Bhojwani [mailto:[EMAIL PROTECTED]] > >Sent: Friday, September 28, 2001 11:44 AM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Performance > >If you don't want Caching you can always select cache-type-mapping as > >"none"....no more caching overheads at Transaction commit time. Also > >selecting the > >default caching option "CountLimited" might not be that bad. I find the > >implementation quite decent. And the overall performance to be quite > linear. > >Performed > >the test with quite a few client threads, stress tested the cache for > >inserts, updates and deletes in various locking modes. May be I will > publish > >my detailed repot > >on the mailing list in a few days. > > > >Thanks ! > >Sudhir Bhojwani > >Altoweb, http://www.altoweb.com > >-----Original Message----- > >From: Liebster, Dan [mailto:[EMAIL PROTECTED]] > >Sent: Friday, September 28, 2001 6:19 AM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Performance > >I would be happy just to be able to force everything in the Castor cache to > >expire immediately with a method call on a single application server. Does > >anyone know if this is possible? > > > >Dan > >-----Original Message----- > >From: James Higginbotham [mailto:[EMAIL PROTECTED]] > >Sent: Friday, September 28, 2001 12:40 AM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Performance > >I have seen a this problem solved in TopLink by using a multicast approach, > >where each instance of Toplink sends an event to all other instances with > >the PK and type (or similiar event data) of the data modified. Whenever a > >retrieve of the data is requested, the particular record is known to be > >dirty and a refresh is made. > > > >Maybe this is a feature best suited to a "commercial grade" version of > >castor, or by someone with a lot of time to write and debug this logic. :) > >Its a nice feature, but one that is rare even in commercial packages > outside > >of TopLink. > > > >James > >----- Original Message ----- > >From: Matthew Baird > >To: [EMAIL PROTECTED] > >Sent: Thursday, September 27, 2001 3:17 PM > >Subject: Re: [castor-dev] Performance > > > >I imagine this is the same problem as running multiple app servers in a > >distributed environment with all of them using different VM's with castor > >banging on the same DB. For adding new objects, there is no problem, but > the > >cache will become inconsistent if there are updates, and castor will not > >like that. Is there any way to accomplish updates for other sources not > >messing castor up? > >-----Original Message----- > >From: James Higginbotham [mailto:[EMAIL PROTECTED]] > >Sent: Thursday, September 27, 2001 1:03 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Performance > >Dan, > > > >In my specific instances, the bulk loading was aggregated by a scheduled, > >background process once and never changed again. The aggregated data is > read > >from castor, so no cache problems occurred. > > > >Anyone from the Castor team that could answer this question, I'm interested > >as well. I have seen TopLink, a very expensive but industrial strength > >mapper, have problems clearing the cache without a hack or VM restart. How > >does Castor deal with this, or does it? > > > >James > >----- Original Message ----- > >From: Liebster, Dan > >To: [EMAIL PROTECTED] > >Sent: Thursday, September 27, 2001 11:57 AM > >Subject: Re: [castor-dev] Performance > > > >When using this approach, I would be interested what techniques you use to > >deal with reading cached objects in Castor that have had the underlying > data > >changed by a batch update. Is there a clean way to "kick the cache" after > >running and external process? > >Dan > >-----Original Message----- > >From: James Higginbotham [mailto:[EMAIL PROTECTED]] > >Sent: Thursday, September 27, 2001 12:13 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [castor-dev] Performance > > > >Chris, > >I have used Castor for basic OR/Mapping and straight JDBC when performance > >is a factor. Speaking from a general perspective rather than from Castor > >benchmarks, one generally chooses OR Mapping tools such as Castor JDO when > >you want to save time and redundant JDBC code. If you need to achieve large > >performance gains when doing complex joins or bulk inserts, you may wish to > >use JDBC batch updates or optimized queries. I have done this on numerous > >J2EE projects using a combination of the Data Access pattern, Castor JDO, > >and JDBC 2.0. > >In short, use Castor to save time on the common CRUD (create, read, update, > >delete) and use straight JDBC for performance gains on bulk inserts using > >batch updates and manually tuned SQL. > >Hope this helps, > >James > >----- Original Message ----- > >From: "Chris Cook" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Thursday, September 27, 2001 10:42 AM > >Subject: [castor-dev] Performance > > > >> > >> > >> I have recently downloaded and started to use Castor for a project. We > >had > >> in place a set of code to simulate a piece of our system, and measure the > >> inserts per second into the database. Using straight JDBC we usually > >> measure about 175 ins/s into the database. With Castor doing the > >> persistence, we measure about 40 ins/s. Does this figure seem right to > >you > >> all? Does Castor average about 4 or 5 times slower than straight JDBC? > >> > >> ----------------------------------------------------------- > >> 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 > > > >----------------------------------------------------------- > >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 > > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
