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