I had thought about the issue, and saw that the finding issue would be one
problem (with object slicing when you requested a B EJBObject through an A
finder). I think that I see a fairly easy, if somewhat kludgy, solution to
this issue. Make your PK be some integral type (short, int, long), and
divvy out IDs in the form of m*X + b. For an inheritance tree, estimate the
maximum total number of nodes you expect to exist in the tree. Estimate
high, as it will be a big deal to change this number after you have some
data in the DB. This number is m. Now each node in the inheritance tree
gets a different b. Note that all values of b must be less than m. X is
the number of instances of the class that have been created before.
So, in our example (we'll assume that we make Shape an entity bean, just to
make it interesting), we will set m arbitrarily to 10. We will give Shape a
b of 0, Triangle a b of 1, and Circle a b of 2.
So we arrange for the first shape to get an id of 10*0+0 = 0. The second
one gets a value of 10*1+0 = 10. The next Shapes are ID 20, 30, 40, etc.
The first Triangle gets an id of 10*0+1 = 1. The next gets 10*1+1 = 11.
The next are 21, 31, 41, etc.
Similarly, the Circle ids are 2, 12, 22, 32, etc.
Now just add "and mod(id) = <b>" to the criteria on each of the finder
methods, and you'll never get back a non-matching class from a finder
method. Of course, that also means that you still can't look up subclasses
as their parent class, but at least you don't get weird slicing that could
cause corruption of the system. You can always make a stateless session
bean to wrapper the base finder methods with ones that support the
heirarchy.
Oh, and I noticed an error, or at least an omission in my example... I
should have pointed out that TriangleData, CircleData are references to the
EJB object that you look up, not to the entity bean object.
Finally, when I said "My first concern was that I didn't know how the
application would know which calls would happen in which transactions." I
didn't mean how the container would know the transactional characteristics
of the methods. I meant that I didn't know how an actual individual
UserTransaction object was associated with an instance of a call into a
method, thus the lead-in to the next statement of how the container might
associate a transaction with a call stack.
The reason I wanted to know was so that I could begin to answer my own
questions about what is and is not safe to do in JBoss.
Thanks, that helped a lot!
Bobby
Cosm development team
----Original Message Follows----
From: "Kenworthy, Edward" <[EMAIL PROTECTED]>
Reply-To: "jBoss" <[EMAIL PROTECTED]>
To: 'jBoss' <[EMAIL PROTECTED]>
Subject: RE: [jBoss-User] EJB design/safety question
Date: Tue, 13 Feb 2001 08:03:03 -0000
MIME-Version: 1.0
Hi Bobby
The thing to remember is that inheritance works perfectly normally. The
issue with EJB entities is that for it to work with them inheritance would
have to work extraordinarily, and it doesn't.
So if EJB entity B extend EJB entity A then B acts in all ways like a
sub-class A. The issues with EJBs are all centred around the home interface.
If inheritance were working properly then calling a find on A's home
interface should return all matching instances of A and all matching
instances of all the sub-classes (children of A, grandchildren of A etc
etc). It doesn't. And that literally is the only problem. The hard bit is
that solving this problem is actually quite tricky, and, in the only
solutions I know of, requires you modify A as you add new sub-classes. And
if you add a new sub-class of B then you have to modify both B and A. This
is "not nice"(tm).
If, however, you don't care about this behaviour then you can freely inherit
between EJB entitys to your hearts content and they will work pretty much
the same as your example (where you have a non-EJB entity base class).
Personally I think I would go with your approach in this case anyway as
Shape is clearly Abstract (it doesn't really make sense to have an Abstract
EJB entity.) Actually that's not quite true. I decided not to use EJB
entities at all (essentially because not even BMP gives sufficient control
over complex relationships between entities but that's another story).
OK so that's set the ecene, down to your questions :-)
>>My first concern was that I didn't know how the application would know
which calls would happen in which transactions.<<
Transactions are defined in the deployment descriptor against the EJB bean
(session or entity). Deployment descriptors are NOT inherited.
>>My conclusion after some thought
was that JBoss likely has a mapping from Thread objects to UserTransaction
objects or some equivalent to track the association of a transaction with a
call stack. Can someone tell me if that is correct, or if not, what the
mechanism is to associate a transaction with a call stack in JBoss?<<
I don't think think this is an issue (ie it works, don't worry about it.).
Hope this helps.
Edward
-----Original Message-----
From: Bobby Martin [mailto:[EMAIL PROTECTED]]
Sent: 13 February 2001 06:00
To: [EMAIL PROTECTED]
Subject: [jBoss-User] EJB design/safety question
Since inheriting EJBs is not safe, is it possible to simply build your
object model as if you weren't using EJB, then build one entity bean for
each persistent object, and some number of session beans to act as the
interface? The entity beans would be a kind of struct that your 'real'
object used essentially as its persistent member variables.
Example:
Let's say you want to model a simple system using EJB. You build:
ShapeMaker (stateless session bean)
Member functions
ObjID makeTriangle(Point2d a, Point2d b, Point2d c)
ObjID makeCircle(Point2d origin, float radius)
void drawShape(long shapeID)
Shape (entity bean)
Member functions
void draw()
//assume standard no-arg ejbCreate and corresponding Home
Triangle extends Shape (entity bean)
Member functions
void draw()
TrianglePK ejbCreate(Point2d a, Point2d b, Point2d c)
//assume home & PK to go with this
Member data
float ax; //(x coord of Point2d a)
float ay; //(y coord of Point2d a)
float bx; //(x coord of Point2d b)
float by; //(y coord of Point2d b)
float cx; //(x coord of Point2d c)
float cy; //(y coord of Point2d c)
Circle extends Shape (entity bean)
Member functions
void draw()
CirclePK ejbCreate(Point2d origin, float radius)
//assume home & PK to go with this
Member data
float origX; //(x coord of origin)
float origY; //(y coord of origin)
float radius;
This can't really be done reliably, if I understand correctly, because
inheritance is not supported by EJB 1.2. (Please disregard the lack of
applicability of EJB to this problem (who wants to draw objects on some
remote server?), it's just meant to be illustrative.) However, will the
following work reliably:
(same ShapeMaker as above)
Shape (non-EJB class)
//same as above, but just use standard constructor instead of ejbCreate
Triangle extends Shape (non-EJB class)
//same methods as above, but just use standard constructor instead of
ejbCreate
Member data
TriangleData data;
TriangleData (entity bean)
//no methods except EJB methods
Member data
//as per Triangle from example above
Circle extends Shape (non-EJB class)
//same methods as above, but just use standard constructor instead of
ejbCreate
Member data
CircleData data;
CircleData
//no methods except EJB methods
Member data
//as per Circle from example above
Now that I've written three pages of example, the question is: Is this
reliable? Is this a common design pattern when implementing EJBs?
My first concern was that I didn't know how the application would know which
calls would happen in which transactions. My conclusion after some thought
was that JBoss likely has a mapping from Thread objects to UserTransaction
objects or some equivalent to track the association of a transaction with a
call stack. Can someone tell me if that is correct, or if not, what the
mechanism is to associate a transaction with a call stack in JBoss?
Thanks much for your time,
Bobby Martin
Cosm development team
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
