Hi, Etzel A better understanding of your specific is needed to get some concrete solutions.
As far as we understand is that you have several different views for the same persistence data. You need to start to think about other factors. For example, Does it require transaction? Like ACID... What is the acceptable performance requirement? Throughput and responsiveness. Is your data structure complex? Is it going to be any mismatch between object and relational table? If you have a strong transaction requirement, I will vote for a traditional DB. Why bother to re-invent ACID? DB gives all the necessary transaction out of the gate. DB does its own cache and proper tuned DB can get you very far. As for the performance requirement, make sure you have measurable way to determine it. Measure, measure and measure. You want to have hard-data to guide you to right direction. If your first architecture choice does not meet your performance requirement, you have to start testing other implementations. We can speculate your core need from the thread but without clear domain knowledge it is hard to come up with an acceptable solution. Michael On Fri, Dec 5, 2008 at 2:45 PM, Alexey Zinger <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
