<vendor>
I assume by Applications you mena the GemStone/J Applications notion I
mentioned below (which is an organizational unit).
Deployment in GemStone/J is via the graphical console (swing based), or via
command scripts. So, to deploy to multiple applications, you simply repeat
the deployment process for each application. If you were scripting this, you
could deploy to each application in parallel.
</vendor>
> -----Original Message-----
> From: David Rauschenbach [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, August 18, 1999 5:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: DB State Management!!, multiple containers
>
> How do you redeploy a component used by <n> applications in GemStone/J?
>
> David
>
>
>
>
>
>
> Chris Raber <[EMAIL PROTECTED]> on 08/18/99 01:37:29 PM
>
> Please respond to A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
>
>
>
> To: [EMAIL PROTECTED]
>
> cc: (bcc: David Rauschenbach/ZLAND)
>
>
>
> Subject Re: DB State Management!!, multiple containers
> :
>
>
>
>
>
>
>
>
> Note: Some recipients have been dropped due to syntax errors.
> Please refer to the "$AdditionalHeaders" item for the complete headers.
>
>
>
> Now that I understand this multiple container/virtual container business:
>
> <vendor>
> In GemStone/J there is a concept of an Application. Applications contain
> components, and all the artifacts that result from provisioning them
> (fleshed out deployment information...).
>
> One can deploy the same bean in multiple Applications, each with its own
> home address and deployment setup.
>
> You can also run multiple GemStone/J systems ( a set of server processes )
> within one federated name space, so you could have the same component
> running in multiple systems too.
> </vendor>
>
> -Chris.
>
> > -----Original Message-----
> > From: Jian Lin [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 18, 1999 9:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: DB State Management!!, multiple containers
> >
> > Is anyone aware of any current EJB servers out there that have multiple
> > container support?
> > I understand that the idea is to enable the deployment of a bean into
> > different
> > containers with
> > different descriptors. Has anyone come across such a need in a
> real-world
> > situation? Since
> > the deployment of the same entity bean in multiple containers causes a
> > cashing
> > problem,
> > it may be less desirable to do it for entity beans than for session
> beans.
> >
> > For different beans, is there any advantage/disadvantage of deploying
> them
> > in
> > the same
> > container versus different containers within the same server?
> >
> > -Jian
> >
> >
> >
> > Hi,
> >
> > Any ideas along these lines ...
> >
> > 1. Maintaining the state of DB when have multiple containers with in the
> > same EJB server?
> > (assuming all of them access the same DB). These containers can be any
> > third party containers.
> > 2. How does it impact caching and O/R mapping tools that are integrated
> > with EJB-Server?
> > 3. How does it impact the "caching" across Containers?
> >
> > If we have different DB being accesed by as single/multipl EJB- Servrer
> > venodors how do Q2 and Q3 effect?
> > Or any other related issues. (Using JMS and JTS may definitely help here
> > IMHO, but I'm interested in the issues and problems dealing with
> > Multiple EJB-Servers/Containers.)
> >
> > Do Q1-Q3 pose same problems when dealing with Multiple Containers in the
> > Same VM as against Containers from a different VM ?
> >
> > Thanks,
> > Nishi
> >
> >
> ==========================================================================
> > =
> > 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".
>
> ==========================================================================
> =
> 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".
