Something like LINQ? All the advantages of SQL except you get type- safety and you can join and project across domains (database, XML, JSON etc.).
/Casper On Dec 5, 8:21 pm, "John Nilsson" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
