Can I suggest that if you are seriously building a banking system and you need to request architectural advice to an internet news group, that you need to cease the project now :o)
But my thoughts: Don't cache above the database unless you have a specific problem with performance you need to solve - any true database performance problem can be solved by a great DBA + good hardware before you need to start doing things in upper tiers. Also keep in mind also that only a tiny percentage of an individuals information is under modification at one time. Someones personal details may change once every 12 months. Even individual account balances may change only a couple of times a day - and be inquired upon only once a day. Thus I would suspicious of the need to broadcast changes to clients of this kind of information. You REALLY really need to understand your data and its usage profile, and then work out from there. Underpinning everything is a good - robust - API on top of a well structured and pragmatic data model backed by good domain knowledge. If you start with that, you can build higher levels of abstraction (JMS/ WS) on top - and i would argue OSGI vs WebServices vs RMI largely becomes irrelevant to the success of your project. On Dec 7, 2:08 pm, "Duncan Mills" <[EMAIL PROTECTED]> wrote: > Of course any extreme view is folly. A huge number of folks in the RDBMS > community regard the middle tier as a really bad place to do anything with > data and advocate that all the application server should care about is > presenting the UI and leave the heavy lifting to the Database, clustering > that if you need to scale. After all the database caches in RAM to, and > what's more it probably has a better chance of choosing the right stuff to > put there. > This approach, of course, is as just as blinkered as the opposing "database > is just a persistence bucket" viewpoint. We have a very rich palette for > Architects to choose from and extremists in either camp are simplyshowing > their ignorance. > Whatever happens, data needs to be versioned and archived in most systems > and so the idea of a purely RAM based system with no structured persistence > to disk (or a disk like medium) seems unfeasible to me, and I suspect, to > many auditors as well. > > Duncan > > On Thu, Dec 4, 2008 at 11:20 PM, kirk <[EMAIL PROTECTED]> wrote: > > > Hi, > > > my 2 cents, avoid using the database unless you really need persistent > > transactional data. No database written today will scale out as fast as > > a reasonably well written distributed Java application. Just about every > > latency problem I run into is either related to GC or DB transactions. > > The DB solution almost always involves injecting some sort of cache. > > John Davies (well known in financial circles) talks about the enterprise > > without a database. Cameron Purdy (Tangosol Oracle) also talks (gingerly > > now that he works or a db vendor) enterprises without a db. He talks of > > a number of latency sensitive systems that never touch disk. All the > > data sits in RAM all the time. Setup properly using replicated cache, > > they have proven that these systems are every bit as reliable as disk > > based systems if not more so. The numbers are telling these guys that > > disk failure rates are much higher than ram failure rates. These aren't > > eveyday home applications, they run 24/7. But now they've been > > architected that way. > > > I wish I had more time to write my opinion on DBs but in short, I > > believe that databases fundamentally a great technology that has managed > > to escape into areas of our systems. This escape was encouraged for a > > number of pretty good reasons that fit with pre-internet bubble thinking > > about how to build systems and pre-2005 changes in hardware. > > Unfortunately we are still being taught to think pre-bubble yet demands > > and hardware require us to think differently. IMHO, we all need to think > > very deeply about the role of RDB in modern architectures. I'm sure that > > there will still be a role there for it though I'm quite convinced that > > it won't be nearly as dominating. To that point, in the interview with > > Ted Farrel, he pointed out that Oracle is finding some interesting and > > unexpected uses for Tangosol. Maybe unexpected for the Tangosol guys but > > certainly unexpected for Oracle. It is solving a number of problems for > > them by taking pressure off of their DB. I see that my post is very > > Tangosol biased. I could say the same for JBossCache, EhCache, > > GigaSpaces, GemStone, Terracotta and a number of others. Pretty much all > > of these guys will tell you that they are friendly with the DB as they > > can't afford to send out a radical message. However privately, they all > > see the DB as an impediment to large system scalability as it is > > currently being used. And these are the guys that know how to scale! > > > Regards, > > Kirk > > > Matthew Kerle wrote: > > > my 2 cents... > > > > don't cache financial / OLTP data, anything thats likely to change > > > within the lifetime of a single release. Bite the bullet and load it > > > from the database. cache things like lookup lists & static data, be > > > very cautious with more aggressive caching without a distributing > > > caching / invalidation mechanism. Database hits are pretty fast unless > > > you have a *lot* of them or some long-running queries, and then you > > > should probably re-examine your architecture and look at hitting > > > pre-built OLAP tables instead or similar... > > > > If you don't mind going the distributed cache route though, then you > > > can look at stuff like EhCache or similar. I haven't looked at these > > > but I assume they would have some sort of integrated invalidation > > > mechanism, but not having used them I can't comment much. Has anyone > > > else used a Java distributed cache and dealt with stale cache / > > > invalidation issues? > > > > cheers! > > > > 2008/12/5 etzel <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> > > > > On 4 Dez., 14:06, Michael Lee <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > I would recommend that you would go with the simplest option B > > > first and > > > > migrate to service-oriented option D. > > > > But it kind of feels a bit dirty having multiple applications > > > accessing the same data the same time. It is a bit like communication > > > through the database. What about caching (Hibernate 2nd Level > > Cache). > > > I would frequently have to invalidate the cache. What about > > > transaction. I'd had a better feeling if there would be only one > > > client that accesses the data. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
