Hi,
scenario:
EJBContainer calls ejbFindByPrimaryKey, no DBMS lookup.
EJBContainer has Bean in it's cache, no DBMS actions.
-> Bean access without DBMS lock.
This might be dangerous if the DBMS concurrency control mechanism is used.
Am I wrong?
Marc
Dave Pinnington wrote:
> I personally do exactly this.
>
> If you image the finder method actually doing a database lookup then you
will be
> doing the following:
>
>
> ejbFindByPrimaryKey() - does database lookup (SELECT)
> if Entity Bean not loaded into server then
> create new EJB inmemory and populate using ejbLoad - (SELECT)
>
>
> So in this case you have done 2 database lookups which i think is much
more
> expensive. The EJB clinet will still get the FinderException whichever
way you
> do it so I always go with the finder simply returning the PK without
doing a
> lookup.
>
> In fact I would go one step further - if ever I have a finder method
(primary
> key or not) where I can get / calculate the primary key withough doing a
> database lookup I will (e.g. composite key etc).
>
> davep
Marc Volz wrote:
> >
> > Hi,
> >
> > I just saw a bea slide which recommends to implement
ejbFindByPrimaryKey by
> > just returning the parameter:
> >
> > String ejbFindByPrimaryKey(String pk)
> > {
> > return pk;
> > }
> >
> > This code does not perfom a database lookup.
> >
> > The above coding has consequences:
> > 1. if a bean with the specified pk does not exist, ejbFindByPrimaryKey
will
> > not throw a FinderException. Instead, ejbLoad will fail (in which case
a
> > FinderException can be thrown).
> > 2. No database lock is set to the tuple with the pk.
> >
> > Has someone out there experiences with the optimized code?
===========================================================================
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".
