Hi Mike,
I sure miss Salt Lake, especially skiing at Alta and Park City. Also, if I
was in Salt Lake today, I would get Ken Jennings on my team....
I don't know precisely how many entity beans we are using, to hazard a
guess I'd say its in the low to mid hundreds.
So around 50 Entity beans? Does these beans represent objects or mapping to
an pre-existing database?
Do you use them for all data access, or strictly for situations where you
need to update data?
The Entity beans models one-to-one with the object model. That is, every
Entity bean has relational database table for persistence. Thus, the use
cases are served by object semantics, not "query to procedure code". The
Local Entity beans are responsible for providing object oriented concurrency
for re-use across applications.
Use them to populate dropdowns, that might have hundreds of rows? (ya, I
know that isn't an ideal situation no matter what the access method, but
when dealing with users, and the users complain that they HAVE to be able to
see ALL the items for ALL vendors...well, I'm sure you've run into similar
situations)
My application is depended on System Reference Tables. For example, if a
disease outbreak occurred, then the user would need to have all available
clinical codes. The codes runs into the thousands per use case context. We
do this by intelligent (use case context) lookups with straight JDBC, no
need for Entity beans here.
How many users? What are their access patterns? Do you have "rush" times??
200 to 300 hundred users on average, over 2000 users on certain peak times.
These 2000 user would create 700k of records thought Entity Beans in a week.
We were experiencing really bad slow downs, even with 3 clustered 8
processor HP-UX boxes, ram maxed for the boxes, running weblogic we were
more or less guaranteed a system crash, until for that application we
switched over to using session beans in front of stored procs ( oracle
backend), now the system moves along swimmingly.
We use 2 SUN 480's with 2 processors and 8 gig mem each. We did have to
optimize the JVM as we learned how production was in reality. The usual
memory leak fixes and garbage collection tweaks. Session beans and stored
procs? Why use J2EE at all. I can't even imagine our application using
stored procs for anything, in fact we only use Oracle for pure data
persistence. I haven't even talked about our large table batch transaction
within J2EE...
That's simply one situation, do you use regular garbage collection, or
incremental, we're starting to see real problems with the system more or
less stopping several times a day in order to gc to occur. When it was 1-2
times a day, that was barely acceptable, now it happens almost hourly.
We don't take garbage collection for granted, its very easy to write code
where the JVM can't detect objects out of scope. Mind you, we use a lot of
DTO's and XML parsing. Use optimizeit, or you'll be sorry. I think the idea
of a perfect automatic garbage collection is a myth...
Yes, I know that the problem could be solved by adding more hardware, but
I also know that it could be solved by switching from entity beans to stored
procs, and from what we've seen the impact on the oracle box is minimal, and
as far as actual cpu load, the only time the load goes above 50% is during
gc, so we've plenty of processor power left. Yes, we've had bea here to help
tune the system, that went no where.
Adding more hardware is really covering up a bad software design problem.
Switching to Stored Procs from Entity beans sounds like you probably never
needed Entity Beans to begin with. It would be totally impossible for our
application to replace Entity beans with Stored Procs. I can't see our
complex object oriented aggregation and association semantics in procedures.
Let me try, ok I would have to lock every associated record and duplicate
this state with embedded SQLs inside stored procedures. Thus, too replace my
state of object graphs, I would have to write tons of more procedural code -
no thanks.
So, this is the basis for my statement about scaling.
Well, what are we scaling?
As for the rest, it just offends my peculiar sensibilities that so many
source and configuration files are required.
Yeah, but just try too imagine the J2EE founders wanting to accommodate
everyone's environment. Actually, I don't mine, because it gives me
deployment flexibilities. Of course, your right, it could be a lot easier.
Mike, remember, J2EE is solving a very complex problem statement. Too write
these distributed transaction frameworks from scratch is way more complex.
Are you attending Borcon? If so, let's meet and talk about this further. Oh
yeah, you're a Delphi guy, this J2EE stuff should be easy :)
Regards,
George de la Torre