Randahl,
EJB's are supposed to be portable server-side components that implement
business logic. Theoretically, an EJB developer should be able to ignore
the backend database and operating system, focusing on the business logic.
The EJB container isolates the EJB components from the OS and db. So, yes,
choosing a specific db is not in the EJB spec.
I might point out that the persistence mechanism for an EJB does not
necessarily have to be a relational database. It could be an object
database, a file-based data storage system, or anything else that can
handle the underlying data. Of course, in practice, it's almost always an
RDBMS.
A web application may or may not use EJBs and databases.
Back in December, Rafael Alvarez wrote:
"Check the docs for the orion-ejb-jar.xml."
"In the entry for entity beans ()
you can specify the datasource and table to be used using the
parameters data-source and table."
"You can find the file in $(APP-DEPLOYMENT-DIR)/$(APP-NAME)/ejb"
You may identify multiple data sources in the
/config/data-sources.xml file. Here I identify two separate
datasources, named "Default data-source" and "MY OTHER DATA SOURCE":
In
/application-deployments/myApplication/myEJB.jar/orion-ejb-jar.xml,
I could specify the following for myEJB:
table="myEjbTable" data-source="jdbc/myOtherEjBDS"
Now, the myEJB should use the desired data source and table, as opposed to
the default.
Note that both of the above datasource url's happen to be HypersonicSQL
"standalone" databases. A HSQL standalone database may only be accessed by
a single user (or client or Orion Server instance) at a time -- use the
HSQL server version for simultaneous access (e.g.,
url="jdbc:HypersonicSQL:hsql://localhost:"), or some other EJB-capable,
multi-user database, such as Oracle.
As I showed last week, the element's values for location,
ejb-location, etc are really names that an EJB container can put in a
naming service and that may be looked up from a client application via
JNDI, but doing so would seem to defeat the purpose of isolating components
and data source details from clients.
Having your client look up a data source via JNDI might be nice for
debugging, but remember that a single-user data source, such as HSQL's
standalone database, will probably not allow a client to log on subsequent
to Orion establishing its connection.
Hope this helps.
Jay Armstrong
[EMAIL PROTECTED]
At 10:49 AM 3/9/01 +0100, you wrote:
>What is the simplest, most server-independent way of using several
>datasources with the same application?
>
>I would like a number of different customers to be able to use the same
>web-application, but with different database instances. It is important for
>me to use as few Orion specific features as possible - so far almost all my
>configuration lies in the standard xml-files as defined in the
>specification. However, it seems choosing a specific database instance is
>not mentioned in the EJB spec.
>
>Randahl.
>
>
>
>