Victor,
Let me state the problem again :
I have 2 database. The user can select any of them before the start
of a session or during the session. Before we used EJB's, we stored the db
properties in the session and whenever the command comes to change the db,
we used to simply reset the session values. The query is performed against
the db as per the db properties stored in the session.
Come EJB's and the situaiton changes. Since we had to change db
connection "on the fly", we proceeded with BMP entity beans. This way,
before the start of any finder/update/create/remove method, we did a
<getconnection(dbProperties)>. This dbProperties is passed as a parameter to
each of these fns. This soln becomes a bit messy and we are not sure whether
it would work properly in a production environment.
So the qn is, is there some place where we can store session values for
the entity bean to refer to? Is it a good idea to store it in a session bean
and these entity beans would query it whenever it needs to get a conneciton?
Would there be a performance issue? Has anybody else faced a similar kind ot
problem?
Thanks.
Raaj.
----- Original Message -----
From: Victor Langelo <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 03, 2000 10:18 AM
Subject: Re: Changng db connection on the fly
> Rajendra,
>
> I'm not sure I understand your problem very well. In the first paragraph
you
> mention needing to deploy beans for different sites using different
databases.
> Where's the dynamic behavior needed in this case. In the second paragraph
you
> are talking about dynamically changing the database connection with each
bean
> invocation. I don't know what a "set fn" is so I cannot comment on your
current
> solution.
>
> I know of no portable way of setting the bean's properties at runtime.
There are
> other approaches that might work. For instance, in a singleton (see
extensive
> list discussion on singletons) you can store a map of bean instances and
their
> dynamic properties. For portability, you may want to use a class bound to
a name
> in the JNDI directory which can easily be accessed by any bean.
>
> --Victor
>
>
> Rajendra Mishra wrote:
>
> > Victor,
> >
> > It probaby would not be a good idea to deploy multiple beans with a
> > different jndi name and then having logic in a session bean/servlet to
call
> > the appropriate bean. What happens if we have 10 sites (using different
> > databases) and there are 10 beans in the system. The beans would have to
be
> > deployed 100 times.
> >
> > I was thinking more in the line of this : Before getting any bean,
set a
> > property which that bean would refer to. What we are doing currently is
we
> > are passing the properties to each and every finder/create methods. Also
> > before calling the set/get, we first set the connection properties with
a
> > set fn. In ejbLoad, we make sure that if we do not have a valid property
> > object setup, then do not initialize the bean. This is working fine but
I
> > was thinking that if we could have some kind of properties associated
with a
> > bean which we can set/change at run-time, then it would be cleaner. Can
> > somebody tell me if this is possible?
> >
> > thanks.
> > Raaj.
> >
> > ----- Original Message -----
> > From: Victor Langelo <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Friday, June 30, 2000 9:50 AM
> > Subject: Re: Changng db connection on the fly
> >
> > > Rajendra,
> > >
> > > Most EJB servers support multiple connection pools. Each pool would
supply
> > > connections to a particular database. The connection info for each
> > database is
> > > part of the pool definition. You're beans would only need to know from
> > which
> > > pool to request a connection. The pool identifier can be saved in a
bean
> > > property. You can pass the pool identifier in the create method of a
> > session
> > > bean. For entity beans, the most portable solution would be to deploy
the
> > same
> > > bean code multiple times with a deployment property identifying the
pool.
> > Then
> > > the business logic would use the appropriate home depending on the
> > database
> > > desired.
> > >
> > > --Victor Langelo
> > >
> > >
>
>
===========================================================================
> 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".
