I think his confusion was thinking that the spec requires one
DeploymentDescriptor per jar file, which is not correct. Yes, each DD is kept
in a separate .ser file within the jar, but there's no reason the Container
can't load the entire jar at deployment, deserialize the DDs, and store them
in a more condensed fashion. In fact, there are several reasons to do exactly
that.
<vendor>
GemStone/J deployment stores the provider jar contents and all generated
artifacts in its persistent repository, where they are immediately (and
rapidly) available to all Container and Bean instances in server VM's attached
to that repository. No file I/O is necessary to access the DD's after
deployment.
</vendor>
-----------------------------------------------------------------------------
"Applying computer technology is simply finding the right wrench to pound in
the correct screw." - Anon.
-----------------------------------------------------------------------------
Bruce Cohen, | email: [EMAIL PROTECTED]
GemStone Systems, Inc. | phone: (503)533-3602
20575 NW Von Neumann Drive | fax: (503)629-8556
Beaverton, OR USA 97006 | web: http://www.gemstone.com
Rickard �berg wrote:
> Hey
>
> Sammy Ballew wrote:
> > In an article discussing new features found in EJB 1.1 in
> > the July '99 issue of "Enterprise Development", author
> > David Linthicum states,
> >
> > "This upgrade to the EJB spec is a relief, as EJB 1.0
> > left a bit to be desired. For starters, EJB 1.0 required
> > a separate deployment file for each bean. This
> > architecture killed scalability, since an application
> > running many beans at the same time will quickly
> > exhaust available resources."
> >
> > Is this true? Does the spec *require* this and if so, is
> > this a scalability issue for 1.0 servers? Has anyone
> > experienced this problem?
>
> Yes, 1.0 was 1 DD/bean.
>
> But the following logic:
> 1 dd/bean -> resource exhaustion -> scalability problems
> is not correct, hence his conclusion is false.
>
> QED. :-)
>
> Did he say any reason as to why this would lead to resource exhaustion?
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
> ===========================================================================
> 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".
