<brief-atopical-note>
Hi. I liked your tagline, and looked up Poul Anderson on amazon, but I can't find
the book "Iron". Can you point me further in that direction?
The only have:
http://www.amazon.com/exec/obidos/search-handle-form/102-1323991-4957633
</brief-atopical-note>
Regarding the coarseness of entity-beans, if you have a fine-grained data-schema in
your RDBMS, then be prepared to have to write some SQL. But the basic idea is that if
you have a whole-part relation (which will always be a 'dependent' relationship on any
properly drawn ER diagram), make an EJB to represent the whole, but provide your own
custom methods for manipulating the parts.
For example, in my first experimental foray into EJB's I normalised like this:
- 1 Person has many Names.
- 1 Name has many Nameparts.
- A namepart does not have meaning outside of a Name
- A Name have meaning outside of a Person.
- A person is a self-existent object which is not dependent on anything else
(...unless you care to model 'Cosmos' into your ER diagram)
This was very extreme for my own interest on the fine/coarse issues, but it's really
only two levels deep, which is fairly common. I used fine-grained entities for each
of the 3 tables, and container-managed-persistence. (Weblogic's JDBC persistence,
which only allowed single tables...if you think about it, a persistence mechanism
which allowed table-joins to be represented by one EJB would run into the same update
problems as you would get trying to update
a database view with a join).
Anyway, on my Person EJB, I had a method called addName(String name), which in turn
made calls to the EJBHome for Name, which in turn made calls to the EBJHome for
Namepart. It performed like a dog. It did have the advantage that if my client
application wished, it could directly inspect a Name or a Namepart with all of the
groovy 'business methods' that such objects can have. Of course, if the client
manipulated the Name or Namepart, then there was network
traffic. But the advantage was automatically persisting things when my client
application changed something.
In this case, there aren't too many manipulations you want to do on a Name or a
Namepart, so it wasn't worth modelling them as EJB's.
In fact, I could get away with a much simpler scheme - have an EJB for Person only,
and have Serializable Name, which held an array of Serializable NameParts.
My addName(String name) method on the Person EBJ now has to do some SQL, which it
didn't have to do before -- to update the Name and Namepart tables directly. That
method executes slightly faster, because it doesn't have to use so much of the EJB
framework (no point in having concurrent, secure, transactional Nameparts, anyway!).
But the real saving is between the client and the server, because setting the value of
a NamePart doesn't involve any network
traffic, you just create a String for the whole name, and send one string across the
network.
The scheme of doing things 'coarsely' mentioned above is broadly referred to as 'pass
by value'. Pass-by-value always outperforms pass-by-(networked)-reference. There
were a couple of papers on the topic written by some of the EJB gurus on the list,
sometime last year, and they are at:
http://www.inprise.com/events/ejbdesign/submissions/Pass-by-Value.html
In particular, the 'Pass by Value' paper by Richard Monson-Haefel is quite relevant to
what I discuss here.
Richard also notes that your Serializable objects should be Immutable - ie. they
should only have public getter() methods. I have been mucking around with
Immutable's and they make life a whole lot easier. It helps if they implement
.equals() and hashCode() correctly too :-) ... (it's really worth the effort!)
That's about it. This might be bad news concerning CMP, but Container managed
persistence is a white elephant anyway - it is not portable between an Object Database
and a Relational Database, because in ODBMS relationships, the ONE contains references
to the MANY, while in an RDBMS relationships, each MANY holds a reference to the ONE.
This obviously affects how you model your EJB's!
Regards,
David Bullock
Russell Gold wrote:
> Every discussion I've seen on entity beans says that they are too expensive to be
>used for fine-grained objects, and should only be used for course-grained objects;
>however, every example I've ever seen on how to do persistence with entity beans only
>shows fine-grained objects, mapping to a single relational table row. Does anyone
>have an example of mapping course-grained entity beans? One that could be used to
>understand the practicality of this concept?
>
> ------------------------------------------------------------------------
> Russell Gold | "... society is tradition and order
> [EMAIL PROTECTED] (preferred) | and reverence, not a series of cheap
> [EMAIL PROTECTED] | bargains between selfish interests."
> [EMAIL PROTECTED] | - Poul Anderson, "Iron"
>
> ===========================================================================
> 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".
--
David Bullock
Project Manager - Strategic Applications
[EMAIL PROTECTED]
"It's no use saying 'We are doing our best.' You
have got to succeed in doing what's necessary."
...Winston Churchill
LISAcorp
http://www.lisa.com.au/
Adelaide Sydney
-------------------- ------------------------
38 Greenhill Rd Level 3, 228 Pitt Street
Wayville S.A. 5034 Sydney NSW 2000
PH +61 8 8272 1555 PH +61 2 9283 0877
FAX +61 8 8271 1199 FAX +61 2 9283 0866
-------------------- ------------------------
===========================================================================
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".
