Thanks, Laurel. Eventually all of our applications will be going through
AppServer so, yes, commit option A might be an option for us that would
help reduce trips to the db.
-M@
--
Matt Hixson
Aventail Corporation
Seattle, Washington
www.aventail.com
On Wed, 26 Sep 2001, Laurel Neustadter wrote:
> The main performance difference I see between authenticating the user in
> every method (by making a trip to the db) and using an entity bean is that
> in the latter case, transaction boundaries will drive ejbLoad() (and hence
> trips to the db). (This assumes Commit Option B or C would be used.) So if
> there are multiple method calls within a transaction, the number of trips to
> the db should be reduced. Using entity beans, however, adds other overhead
> (e.g., the container intercepts every call).
>
> If you can use Commit Option A, the number of ejbLoad() calls would be
> reduced even more. Based on your message, however, it sounds like
> applications other than the J2EE one update the authentication data. If this
> is the case, Commit Option A is not applicable.
>
> Of course, the best way to determine the best architecture is to prototype
> one and test it. Hard to say in theory what option will perform best.
>
> Laurel
>
> -----Original Message-----
> From: Matthew Hixson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 25, 2001 5:22 PM
> To: [EMAIL PROTECTED]
> Subject: Re: representing login info with entity beans?
>
>
> Do you do authentication on every single method call? That is what we're
> thinking about doing. The problem is that if we place a boolean flag
> inside a statefull session bean to indicate that the user has been
> authenticated (using another stateless session bean) then that flag can
> become dirty if an administration app decides to disable that user's
> account.
> This dirtiness problem can be gotten around by using a stateless session
> bean to authenticate the user, but making a trip to the db on every method
> call just to authenticate the user (let alone how many db calls it might
> take to perform the business logic) seems rather expensive.
> I was thinking that it might make sense to represent the user's
> authentication information with an entity bean. This way administration
> software that manages users' accounts and client software that
> authenticates the users can be kept in sync. If a user is logged in to
> our web application and an administrator disable's that user's account
> then the next action attempted by the user would be disabled. We much
> prefer this over allowing the user to keep doing whatever they want until
> they logout and attempt to login again.
> Anyone care to comment on this problem?
> -M@
>
> --
> Matt Hixson
> Aventail Corporation
> Seattle, Washington
> www.aventail.com
>
> On Tue, 25 Sep 2001, Senthoorkumaran wrote:
>
> > I think using a session bean in this case is better. Keep it stateless
> > too if possible. What we have done is written a Oracle package which
> > will authenticate the user and at the same time will returns some
> > necessary field to the front end in the same call which we will be
> > working with. For example the use name and password could be passed and
> > may be if it is authorized user we could send back
> > SessionTimeoutInterval, FirstName, LastName.
> >
> > We are using session bean for this purpose and it works well.
> >
> > Senthoor
> >
> >
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Hixson
> > Sent: Tuesday, September 25, 2001 5:46 AM
> > To: [EMAIL PROTECTED]
> > Subject: representing login info with entity beans?
> >
> > I am working on a project where we need to repeatedly authenticate
> > access
> > to a session bean method. Due to some technical restrictions we can't
> > use
> > cookies to authenticate a session. Some piece of client software may
> > need
> > to access the same session bean method a hundred times in a row, but we
> > have no way of knowing (from the server side) whether or not those
> > requests are coming from the same client. There also may be many
> > clients
> > accessing the same method at the same time.
> > Username and password information is stored in a database. Would it
> > significantly increase performance to represent the username/password
> > information with an entity bean so that the container can cache that
> > information instead of making a trip to the db each time?
> > Anyone else out there had to solve a similar problem?
> > -M@
> >
> > --
> > Matt Hixson
> > Aventail Corporation
> > Seattle, Washington
> > www.aventail.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".
>
===========================================================================
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".
