In general, it's time to raise the abstraction layer around data storage and retrieval. Millions of developers have been fighting the impedance mismatch between relational data and object graphs. Instead of aiming for SQL dialect neutrality as we've typically done in the JEE world, we really should be thinking of a "super JDBC" to get us persistence neutrality. This is what LINQ/PLINQ did on the .NET platform and it's truly revolutionary in how it bridges OOP with a declarative query syntax... on top of whichever storage container you see fit. But please, let's not stuff more logic and behavior into the belly of a beast that does not scale and which represents a major vendor lock-in.
On May 13, 3:18 pm, Alexey <[email protected]> wrote: > I agree that doing your own IO work inside a relational DB is not a > good thing. But what about the general idea of being able to define > and manipulate objects next-door to a relational world? What about > putting your object-relational mapping into something like Oracle? > Having available garbage collection, a good compiler, a unified tool > chain and so on? I don't see those things as drawbacks in and of > themselves. I've seen plenty of horrendous PL/SQL code that was that > way because complicated OOP-like things were attempted, but had to be > done in Oracle in the name of speed (rightly or wrongly is hard for me > to say right now). > > On May 12, 8:45 pm, RogerV <[email protected]> wrote: > > > > > > > I'm in a shop where I have PL/SQL devs, Java devs, C# devs, HMTL/ > > JavaScript web devs, Adobe Flex devs, and combinations thereof. > > > On the Oracle back-end - the Oracle RAC is expensive to license and > > although it offers some HA (you can take a server node in and out of > > the database cluster), it really only seems to scale well up to about > > four servers. Maybe others take it higher but you get into contention > > with the SAN/clustered file system, sequences that have to be > > synchronously incremented instead of managed via block reservations, > > and getting the configuration uniform across all database nodes all > > the time is a bit painful to manage (particular for lots of customer > > sites of Oracle RAC installations). > > > As such, I don't think it makes sense to pile application code into > > the Oracle back-end (we have a lot of PL/SQL legacy app code that is > > exactly that and we're in process of migrating it to the middle-tier > > and even the client-tier as we rewrite the app). > > > We also have bits here and there that is Java running in the Oracle > > database. There are some areas of functionality that are only provided > > in Java. And in the past we had devs write some Java instead of PL/SQL > > (we'd never do that now, though). > > > I really dislike the Java in the database. If you want to use a a > > library that is already there, it's a real pain to deploy it there > > (relative to just add a library to the Maven build of a .war file that > > gets deployed in Tomcat). The RAC can also complicate that situation > > further. Plus you don't have threads in the database, so the way you > > might do asynchronous things in normal Java, you would not do that way > > when running Java code inside the database. Plus I've mandated the > > rule to my devs that no i/o will be performed from the database - only > > database transactions. Doing any manner of i/o from the database is a > > formula asking for trouble (like transactions that get blocked waiting > > for network i/o timeouts to happen, etc.) > > > I really can't think of a worse idea than running Java code inside the > > Oracle database. Some performant PL/SQL package code or views, I'm > > entirely alright with. Java should be out in the middle-tier, though. > > > -- > > 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 > > athttp://groups.google.com/group/javaposse?hl=en. > > -- > 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 > athttp://groups.google.com/group/javaposse?hl=en. -- 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.
