I take the idea of using shared memory for persistence as the call to designing good API in place of relying on RDBMS queries. And in a way, we do so already. Isn't the whole idea of using an ORM to abstract RDBMS away from your object world and present data through OOP-friendly API?
Alexey 2001 Honda CBR600F4i (CCS) 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net --- On Fri, 12/5/08, John Nilsson <[EMAIL PROTECTED]> wrote: > From: John Nilsson <[EMAIL PROTECTED]> > Subject: [The Java Posse] Re: Architecture - Multiple web apps operating on > the same data > To: [email protected] > Date: Friday, December 5, 2008, 2:21 PM > What do you use as quey language in these kinds of system? I > can see how an > RDBMS isn't really needed for persistance. But they do > have quite advance > query engines. What is the replacement? > > BR, > John > > On Fri, Dec 5, 2008 at 8:20 AM, 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 -~----------~----~----~----~------~----~------~--~---
