I didn't really intend to start a discussion of whether or not JDBC
should be used from clients; I'm fully aware that it violates the EJB
paradigm of separating presentation from business logic. But the J2EE
spec allows for it, so I'm rather curious about how it is implemented.
This all started as a thread on the Orion-Interest list started by a guy
who found that he was able to dramatically increase the performance of
his client applicaiton by accessing records through JDBC. I don't know
what he was doing or why he needed the logic in the client, but I'm
willing to set that aside. He found that he didn't need to package the
JDBC driver with the client when using WebLogic, but hasn't figured out
how to make Orion behave in like fashion.
This has provoked some debate about how this all works that nobody has
been able to answer. Richard, your comments about WebLogic have shed
quite a bit of light on the subject. Thank you!
Now I'm even more curious: What do other application server vendors do?
It seems like implementing this JDBC proxy would be a lot of effort for
something that would so rarely be used.
Jeff Schnitzer
[EMAIL PROTECTED]
No, *I* haven't committed such a two-tiered transgression, and don't
plan to... but I've just gotta know how *everything* works :-)
>-----Original Message-----
>From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 07, 2001 6:34 AM
>To: [EMAIL PROTECTED]
>Subject: Re: How does JDBC from application clients work?
>
>
>Peter Miller wrote:
>
>> Jeff,
>>
>> The whole idea about this architecture, commonly call
>multi-tier or n-tier,
>> this that there is a separation between client presentation
>logic, business
>> logic and state persistence, in that order. So clients
>should deal only in
>> presentation issues, and request business process execution
>of the server.
>> It, in turn, validates and manipulates various objects and
>they persist
>> their state to a store (typically an RDBMS).
>>
>> So, the answer is, clients should not access JDBC at all, never!
>
>I'm not sure I agree with this statement. Before EJB a lot of
>people, including
>myself, were busy writing database gateways or brokers that
>allowed clients to
>obtain thin JDBC driver connections that were multiplexed by a
>central server.(
>2-Tier was still king at that time and even Java-CORBA as in
>its infancy.) In
>other words the JDBC-broker ensured that JDBC connections were
>pooled and
>shared across clients, which make 2-tier systems more
>scalable. As a matter of
>fact, the Weblogic was originally an independent company that
>got its start (I
>believe) as a JDBC driver and JDBC-broker vendor. They
>provided a lightweight
>specialized JDBC driver that communicated client request over
>the network to a
>broker, which then redirected the requests native JDBC drivers.
>
>Anyway, using JDBC directly from clients in a 2-tier system is
>still a viable
>solution if you use the right technologies. 3-tier is great,
>but its not for
>everyone.
>
>Richard
>--
>Richard Monson-Haefel
>Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
>Co-Author of Java Message Service (O'Reilly 2000)
>http://www.EjbNow.com
>
>===============================================================
>============
>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".
