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]
