I haven't actually used LINQ so my understanding might be a bit flawed. But from what I have seen LINQ is rather limited in performance. Doesn't it kind of default to just pulling up the table in RAM and do filtering and joins on the fetched data? Also if it's anything like HQL I assume that it suffers from the same shortcommings wrt complex relational expressions. (The problem with HQL stems mainly from not supporting subqueries in the from clause though..., but there are lots of other short commings that make it practically worthless for anything but simple data fetching.)
What I wan't from a query language is not just a neat way to express iteration but a high level declerative language to express any kind of data analysis and a reasonable expectation that the query will be executed in a performant and non wastefull way. OTOH I might be mixing requirements under the same umbrella here, maybe HQL/LINQ is exactly the right sollution for the intended problem and I just lack a complementary sollution for the other problem... BR, John On Fri, Dec 5, 2008 at 10:40 PM, Casper Bang <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
