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 at http://groups.google.com/group/javaposse?hl=en.
