I saw a LOT of people with interest in complementing J2EE with Aspects, and
I saw a LOT of people with interest in *replacing* J2EE with Aspects. Not
sure which approach (if either) is going to prove to be the "best" way of
doing things, but some very interesting discussions where had all around,
including one I had with an engineer from the core infrastructure team at
WebLogic.
Security wsa a topic that wasn't discussed heavily because it's one of those
things that people get *very* sensitive about *very* quickly, and they
really had too many other things they wanted to get to. Still, I can see a
number of places where aspects can very easily (once you understand the
concept of what they're doing) slip into a normal call graph to provide
out-of-band contextual information (they call it the "wormhole effect") to a
downstream call, which is almost always what a security system wants to do
at some point.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
----- Original Message -----
From: "John Harby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 12, 2002 8:23 AM
Subject: Re: [EJB-INT] EJB reference in Java Pet Store(thread safe???)
> OT - Ted, thanks for the info about the Aspect workshop. It was excellent.
> Do you see anyone interested in integrating it into the J2EE framework? I
> would love to see this in security authorization especially because
> customers I see always end up growing their own.
>
>
> >From: Ted Neward <[EMAIL PROTECTED]>
> >Reply-To: Ted Neward <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: EJB reference in Java Pet Store(thread safe???)
> >Date: Sat, 12 Jan 2002 01:42:37 -0800
> >
> >Section 6.5.6 of EJB 1.1 supports your view:
> >
> >"IF a client-invoked business method is in progress on an instance when
> >another client-invoked call, from the same or different client, arrives
at
> >the same instance, the container must throw the java.rmi.RemoteException
to
> >the second client."
> >
> >In the EJB 2.0 spec, though (assuming the Aug 14 2001 release is still
the
> >final release), there is a footnote at the bottom of the page after that
> >exact same sentence (this time in section 7.5.6, p 76) that states that
the
> >container may queue or serialize the calls, implying that the calls will
> >simply block until the first call completes. Hence my posting.
> >
> >Net result--clients cannot assume anything, and had better synch
> >themselves,
> >which I believe is exactly your point. We've come to violent agreement.
:)
> >
> >Ted Neward
> >{.NET || Java} Course Author & Instructor, DevelopMentor
> >(http://www.develop.com)
> >http://www.javageeks.com/tneward
> >
> >----- Original Message -----
> >From: "Ian McCallion" <[EMAIL PROTECTED]>
> >To: "Ted Neward" <[EMAIL PROTECTED]>
> >Sent: Friday, January 11, 2002 4:29 AM
> >Subject: Re: [EJB-INT] EJB reference in Java Pet Store(thread safe???)
> >
> >
> > > Ted Neward wrote:
> > > >
> > > > They *could* become a shared resource, however, if the client runs
> >multiple
> > > > threads against the same session bean reference, which is quite
common
> >in
> > > > servlet applications....
> > > >
> > > > The EJB Spec guarantees that only one method call at a time will be
> >allowed
> > > > on any Bean, IIRC, so other callers will be blocked on any bean
method
> >until
> > > > the first method completes and returns.
> > >
> > > No. The spec guarantees only one method call at a time will be
allowed,
> >but
> > > containers don't do the synchronisation. So if you don't synchronize
> >access to
> > > EJBs (EJBHomes and EJBObjects) from servlets you'll get exceptions
> >raised
> >when
> > > race conditions occur. This is not necessarily simply a matter of
> >putting
> > > synchronize() blocks around the calls to the EJB for two reasons:
> > >
> > > 1. For very high thruput applications synchronizing calls to EJBHome
may
> >cause a
> > > bottleneck, so get a new copy of the EJBHome object whenever needed.
> > >
> > > 2. When viewing a page containing buttons that invoke your servlet a
web
> >user
> > > can click the buttons multiple times and if this happens your servlet
> >will
> >get
> > > multiple requests from the user that may be processed in parallel on
> >different
> > > threads. This potentially nasty situation that can cause several
> >problems - not
> > > just the problem of parallel invocations of EJBs, so cast your
> >synchronization
> > > net wide, and carefully choose the object to synchronize on - the
> >EJBObject may
> > > not be appropriate since it may not always exist.
> > >
> > > Ian
> > >
> > > ========================================
> > > Ian McCallion
> > > Alexis Systems Limited
> > > Romsey, UK
> > > Tel: +44 1794 514883
> > > Fax: +44 1794 501692
> > > ========================================
> > >
> >
>
>===========================================================================
> >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".
> >
>
>
>
>
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
===========================================================================
> 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".
