Board index » jbuilder » what is academic in j2ee?

what is academic in j2ee?


2004-07-16 05:12:25 PM
jbuilder17
news.com.com/More+than+an+open-source+curiosity/2008-7344_3-5271084.h
tml?tag=nefd.lede
Nice reading anyway, but what does he mean when he says that j2ee is
academic?
 
 

Re:what is academic in j2ee?

"Buch" < XXXX@XXXXX.COM >wrote in message
Quote


news.com.com/More+than+an+open-source+curiosity/2008-7344_3-5271084.h
tml?tag=nefd.lede

Nice reading anyway, but what does he mean when he says that j2ee is
academic?
IMHO Entity beans, especially, they just don't scale well in my experience.
Most projects I've seen still ignore concurrency issues using jsp, its just
last
edit wins.
All those friggin XML configuration files.
The list is longer, but my time is short, so I'll leave it here.
</putting on flame retardant undies>;)
Mike
 

Re:what is academic in j2ee?

Quote
"IMHO Entity beans, especially, they just don't scale well in my
experience."
You should qualify your statements.
I have over 250 Entity beans in our application, in my experience they scale
extremely well.
The 250 Entity beans are mapped one to one with our class diagram design,
oh - did I say it scales extremely well...
IMHO,
George
"Mike Mormando" < XXXX@XXXXX.COM >wrote in message
Quote

"Buch" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>
>

news.com.com/More+than+an+open-source+curiosity/2008-7344_3-5271084.h
>tml?tag=nefd.lede
>
>Nice reading anyway, but what does he mean when he says that j2ee is
>academic?

IMHO Entity beans, especially, they just don't scale well in my
experience.
Most projects I've seen still ignore concurrency issues using jsp, its
just
last
edit wins.
All those friggin XML configuration files.
The list is longer, but my time is short, so I'll leave it here.
</putting on flame retardant undies>;)
Mike


 

{smallsort}

Re:what is academic in j2ee?

"George de la Torre" < XXXX@XXXXX.COM >wrote in message
Quote
>"IMHO Entity beans, especially, they just don't scale well in my
experience."

You should qualify your statements.
Usually, using IMHO, and "in my experience" are considered qualifying your
statements.
Quote

I have over 250 Entity beans in our application, in my experience they
scale
extremely well.
I'm very happy for you, 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. Do you use them for all data access,
or strictly for situations where
you need to update data? 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)
How many users? What are their access patterns? Do you have "rush" times??
In the business I'm currently working for, we've got some 500 locations that
always wait until the last day to put in their orders.
They must have their orders in by 10AM mountain time on Thursday, they could
put them anytime beforehand, in fact, they've been STRONGLY encouraged to do
so, but, there you are, the system just goes nutso from 7-10 am thursday
mornings.
What are you going to do?? 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.
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. 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.
So, this is the basis for my statement about scaling.
As for the rest, it just offends my peculiar sensibilities that so many
source and configuration files are required.
1 ejb, 1 source file, 1 xml file, anything more is just wasted space.
Again, that is just my personal peccadillo, so YMMV.
I'm really interested in how ejb 3.x is shaping up, and have already started
investigating it, so maybe things will change
Mike
 

Re:what is academic in j2ee?

Middle tiers was all about avoiding licence fees, with good side effect
about easier switching of databases ... now when that is not rellevant any
more,
good old stored procedures rules again ... :))
Those who have multilayered apps can easily switch to SP calls.
 

Re:what is academic in j2ee?

"Buch" < XXXX@XXXXX.COM >wrote in message
Quote
Middle tiers was all about avoiding licence fees, with good side effect
about easier switching of databases ... now when that is not rellevant any
more,
good old stored procedures rules again ... :))
Those who have multilayered apps can easily switch to SP calls.


Actually many of the big DB vendors take middle tier stuff into account when
charging for licenses.
Mike
 

Re:what is academic in j2ee?

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....
Quote
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?
Quote
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.
Quote
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.
Quote
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.
Quote
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...
Quote
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...
Quote
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.
Quote
So, this is the basis for my statement about scaling.
Well, what are we scaling?
Quote
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