Hi James,
<vendor>
I am not exactly sure why you are doing what your doing but I can make one
comment with regard to performance. IAS (Inprise) allows for the ability to
load the state when performing the initial query, which can give you a
significant performance boost.
Your proposed solution will not be able to take advantage of this
performance enhancement thus if your generic finder returns N numbers of PKs
you container will need to perform 1 + N sql calls. N being the select calls
for each bean instance. This will be slow if N is large. **** Please note
that the load state flag is a deployment setting for your cmp entity beans
thus can be turned off depending on your use case. *****
A way to overcome this, in *** some cases *** (where the pk is a simple
field), would be if all your entity beans home had a method like
findByPrimaryKeys(String[] keys) and your containers cmp engine was able to
dynamically generate a select clause like 'select * from sometable where
pkfld in {?,?,...,N-1}', where 0 and N-1 are the array bounds. This would
save on the N remote calls to the database. This feature is scheduled for
IAS 4.1.
By the way does your solution mean that your generic bean has a connection
to the different databases of your entity bean and has knowledge of their
persistence across the board.
</vendor>
kind regards
-william
Inprise Europe
-----Original Message-----
From: James Webster [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 03, 2000 6:40 AM
To: [EMAIL PROTECTED]
Subject: A possible solution to 'polymorphic finders'?
Hello all,
Please consider the following pseudo-code as a possible solution for
polymorphic finders (this example assumes the existence of an entity bean
X, that is extended by entity bean Y)
public class EntityXFinderBean // a stateless session bean
{
public EntityX[] findBySomeValue(SomeValue aValue)
{
SELECT pk FROM EntityXTable where someField = :aValue
while (ResultSet has more records)
{
Get Primary Key from ResultSet.
Get most derived type of instance from Primary Key // (ie.
the Primary Key encodes the name of the instance's most
derived type, which could be X or Y depending on what
we inserted)
Lookup the name of the home interface for the derived type.
Call findByPrimaryKey on the home interface, passing in the
Primary Key.
// This step may require either the use of
Method.invoke() to work correctly,
Add the returned remote reference to the array of results.
}
}
}
So,
1. This solution results in extra classes, beans that you wouldn't
otherwise have (of course, you could have one FinderBean for a range of
classes).
2. I am not sure whether this would necessarily perform significantly
slower than a regular ejbFindByXxxx() call. When does an app server call
ejbLoad to bring an entity bean into existence (assuming it isn't already
in memory) - right after ejbFindByPrimaryKey is called - or once a client
makes a method call on the remote reference.
We're currently priding ourselves on what looks like a reasonable solution
to the problem, but I'm keen to have someone shoot this one down if there
are glaring flaws we're overlooking (other than, the EJB spec should
specify a decent solution for inheritance!)
Regards,
James W.
--------------------------------------------------------------------------
Visit us at Cards Australia 2000 on Stand 31A. Cards Australia will be
held at the Melbourne Convention Centre from July 4-6 2000.
--------------------------------------------------------------------------
This e-mail is from Cards Etc Pty Ltd (ACN: 069 533 302). It may contain
privileged and confidential information. It is intended for the named
recipient(s) only. If you are not an intended recipient, please notify us
immediately by reply e-mail or by phone on +61 2 9212 7773 & delete this
e-mail from your system.
--------------------------------------------------------------------------
===========================================================================
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".
