Hi Curt! Hope you're not pissed off at me anymore ;)
Serializing may or may not be needed, but I think *choice* should be left to
the System Architect or
whoever that designs the system. There are some nasty, perhaps fatal
consecuences of not doing it this
way(not the only solution, of course). Transaction isolation and transaction
locking (also record locking)
have been a thoroughly discussed issue at EJB-INTEREST. Most(bah, all)
banking systems I know of serialize
their transactions(either by using singletons, MQ, or DB Transacion
isolation).
This is specially true when optimistic record locking gets mixed with
concurrent transactions; I suggest you check
back further on the list about these issues.
Also, bear in mind that EJB is a broad spectrum specification; now, or at
some point in the future, it must
integrate seamlessly with CORBA objects, COM objects, existing RDBMS's, MQ's
(and any other form of persistance management that
supports transactions like in the connector specification which should
enable to integrate with persistance enabled systems ranging from LDAP to
SAP). It must also allow for multi JVM/host clustering of applications
One size fits all just isn't true. The spec is maturing is true. But
remember
that it is indeed difficult to get all the angles on J2EE.
Still, many of your points stand up(specially regarding performance), but
this can be helped with careful system design; if performance is the only
valid point(not time to code or total cost of ownership), why use OOP at
all?
My 2c,
JP
-----Original Message-----
From: Smith, Curt H. [mailto:[EMAIL PROTECTED]]
Sent: Viernes, 12 de Enero de 2001 10:36
To: [EMAIL PROTECTED]
Subject: Re: Caching anyone
> > CMP. It's a pipe dream of the EJB spec writers that not having
> > to know your data and how to optimally access it (writing good
> > sql) is some how possible. Remember these ideas were brought
> > to you from the same bunch that think forced serialized calls
> > into a bean is from a whole system design perspective a good
> > idea. :))
>
> If this is really what you think of EJB it is difficult to
> see why you bother
> with this mailing list - server-side applications are not
> simply multithreaded
> fat-client applications on a bigger box.
Reentrant beans causing fat clients an need for bigger box???
Non-rentrant beans makes for thin clients and small boxes??? LOL
Look again, serialized calls into non-rentrant beans is one of the
causes for EJB being low performing, RAM and CPU consuming when
compared to the benefits to reentrant beans and fewer objects handling
more client calls more efficiently. The complexity in the container
to track reentrant calls from same client, different thread etc etc
must bloat out the container, IMHO.
>From a robustness and code completness perspective; this is where
you need to move from simplistic example code to production code
that works even when 10k customers have hit your site:
- Client calls on an EJBObject must catch vendor specific exceptions
when the container has created the max number of beans in the pool
and vendors like Weblogic throw an execption back to the client
due to peak demand exceeded the container's pool size tuning.
When your container can't handle another method call on the bean,
what does the client do?? Loop 3 times on the bean.method() call????
You tell me?
Why not queue method calls?
Why not offer a quality of service property that you queue for this
time then time out...
- Or why not just put back the RAM efficiency
into the server side, remove the complexity from the client side
and support the corba'esk / RMI service dispatcher'esk mode of sharing
a single instance of an object for all method dispatches???
<robustness commercial code issue>
- When you look at the whole system design, the code that now is pushed
onto the client designer for mission critical, serialized calls into
beans has many side effects that some how this list has not adequately
discussed, IMHO.
</robustness commercial code issue>
> The problem with dismissing OR and CMP so comprehensively is
> that without them
> (or something like them) you can too easily finish up writing
> monolithic
> procedural COBOL/CICS-like.
Hmm? :)
curt
Curt Smith
Z-Tel
email: [EMAIL PROTECTED]
work: 404-237-1166 x182
FAX: 404-237-1167
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
