Sorry for the slow answer. My mail server was down yesterday.
The EJB specification does not include any enhancements to database
connection pooling that I am aware of. An EJB will typically connect to the
database the same way that a regular JavaBean will. The only exception to
this is when you create a special type of EJB called an entity bean with
container managed persistence. In this case you simply define a class with
member variables and the container (i.e. JRun), is responsible for accessing
the database and storing or retrieving the information. The EJB spec does
not dictate how the container talks to the database.
The EJB spec does include automatic transaction handling, however. You can
configure your container to automatically wrap calls to your EJB in a
transaction so that a failure results in an automatic rollback of any
database changes.
For our project we are using JDBC 2.0 Data Sources. A Data Source is an
abstract representation of a database. Your code is setup to connect to the
data source instead of the database. Every data source is given a name, and
that name is the only thing that is hardcoded in your source code. Your
code makes calls to JNDI to retrieve the data source object which in turn
can give you connections to the database. At deploy time the administrator
can specify which database the data source is bound to. In JRun's case this
is done in the JRun Management Console under JDBC settings. Using a data
source makes it possible to change the database you are talking to without
modifying any code.
Data sources also handle connection pooling for you automatically. You ask
the data source for a connection and it gives you one. When you are done,
you close the connection and it automatically returns to the pool.
Your JDBC driver must support JDBC 2.0 before you can use data sources. We
are using the Oracle thin driver.
We have a simple class called DBConnectionFactory which knows how to look up
the data source via JNDI and return a connection. Any EJB that needs to
talk to the database simply calls a static method of this class called
getDBConnection().
I hope this helps.
-----Original Message-----
From: Celeste Haseltine [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 12:59 PM
To: JRun-Talk
Subject: RE: how to deploy Entity Bean
Mark,
I too have NOT used EJB's, so this may be a stupid question, but it came to
mind when I read your message. If you decide to use EJB's, particularly to
access your database to hand information off to a JSP on a different server,
does that eliminate the need to purchase a third party JDBC driver that
handles connection pooling, etc? In essence, is it easier to write your own
EJB that handles connection pooling, or is it still easier to use a third
party JDBC driver within your EJB code to handle that for you?
Celeste
-----Original Message-----
From: Mark Phelps [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 11:48 AM
To: JRun-Talk
Subject: RE: how to deploy Entity Bean
See Chapter 28 in the "Developing Applications with JRun" manual for
information about container managed persistence and entity beans in JRun.
Electronic documentation is present even when you download an evaluation
copy. I have never used CMP entity beans with JRun so I can't give you
exact details.
To answer Eric's question, here are a few differences between EJBs and
regular JavaBeans.
1. EJBs are a remote procedure call technology, meaning that the client
software using an EJB, (such as a JSP page), does not have to be running on
the same machine as the EJB. This can be a great benefit when you are
creating large systems that must scale. It is also helpful for client/server
systems where the client code is never on the same machine as the server.
JavaBeans are just standard classes and must run on the same machine as the
class that is using them.
2. EJB containers provide services which you can take advantage of without
writing any special code. For example, EJB containers manage threads and
database transactions for you automatically in most cases.
3. You can also use container managed persistence, (as mentioned in
Sanjeevi's original question), which means that you don't even have to write
any database code to make your object persistent. In other words, the member
variables in your object are automatically saved to a database when the
object goes away. When the object is recreated, the information is
automatically loaded from the database to the object in memory. The database
is always kept in sync with the object in memory.
In general, EJBs are very good for modeling the business logic tier in a
scalable, reusable way. One EJB can be used in a multitude of systems.
When combined with JSPs and Servlets for the presentation tier they make a
powerful base for web applications.
Most of the things you would do with an EJB can be done with JavaBeans but
you lose out on the benefits mentioned above. On the other hand, while EJBs
may make database transactions and thread handling easier, they are
generally harder to develop and deploy than JavaBeans. It took me two weeks
just to figure out how to code an EJB, successfully deploy it to JRun, and
then access it from client code. If your project is small to medium in size
and does not need to scale past a single server, it may be better to stick
with JavaBeans.
I don't believe in using technology just because it is there.
-----Original Message-----
From: Eric Cheng [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 9:59 PM
To: JRun-Talk
Subject: Re: how to deploy Entity Bean
Hi,
Would someone tell me the benefit of using EJB?
What's the difference between EJB and JB?
Your feedback if highly appreciate
Best Regards,
Hogi
----- Original Message -----
From: Sanjeevi Athreya <[EMAIL PROTECTED]>
To: JRun-Talk <[EMAIL PROTECTED]>
Sent: Monday, May 29, 2000 4:13 PM
Subject: how to deploy Entity Bean
> Hi
> New to EJB, can U please tell me how to deploy a Entity Bean I mean I
tried
> using WEBLOGIC , I am right now reading EJB by OReilly and he says there
is
> a interface to map the persistant fields with the DB fieids.
> I want to know if JRUn provide a interface like this.
>
> Some one told me WEBLOGIC does
>
> please help
> thanks
> regards
> Sanjeevi
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
