One of the advantages of Java in Oracle is eliminating network latency in situations, where it's difficult to express a batch job in PL/SQL: http://www.informit.com/articles/article.aspx?p=170870
On May 13, 10:10 am, Jess Holle <je...@ptc.com> wrote: > Java within Oracle is a different beast than what you're used to in some > ways. > > For instance, as I recall the classloaders are isolated to a transaction > and so any classes used are reloaded in each transaction, which can > really kill performance if you have a lot of classes to load to > accomplish the task at hand. Perhaps this has changed, but my > recollection from the Java Posse interview on this topic is that this is > intentional and not-changing. [This seems like a golden opportunity for > a read-only, pre-clinit class cache.] > > On 5/13/2010 8:18 AM, Alexey 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<rog...@qwest.net> 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 javapo...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> javaposse+unsubscr...@googlegroups.com. > >> 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 javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
