Thanks Jay,
What I've done to bypass the problem for now is to implement the many to
many mapping in JSP. Yep you read right, JSP:
and example snip to find all devices associated with Nokia would be:
<mywds:organisation description="Nokia">
<mywds:results name="organisation">
<mywds:organisation_device organisationId=<jsp:getProperty
name="organisation" value="id">>
<mywds:results name="organisation_device">
<mywds:device id=<jsp:getProperty name="organisation_deivce"
value="device_id">>
<mywds:success>
<select name="device_id">
</mywds:success>
<mywds:results name="device">
<option value=<jsp:getProperty name="device"
value="id">><jsp:getProperty name="device" value="name">
</mywds:results>
<mywds:success>
</select>
</mywds:success>
</mywds:device>
</mywds:results>
</mywds:organisation_device>
</mywds:results>
</mywds:organisation>
This means that when the tags find entities, then they are loaded, not
before and it saves on startup time and memory space. Probably not the best
way of doing it but it works, it's pretty fast and I don't have to copy and
paste so much between beans!
Two problems: one the JSP pages are getting a bit big, two the JSP
programmers take a little longer to understand the theory.
Thanks again and please post again if you have any more ideas,
Tim.
-----Original Message-----
From: Jay Armstrong [mailto:[EMAIL PROTECTED]]
Sent: 12 January 2001 14:46
To: Orion-Interest
Subject: Re: mapping of existing m2m tables
Hi Tim,
Sounds like you've implemented this with Entity EJBs. I could be wrong,
but most J2EE platform products (WebLogic, Orion, etc) implement Entity EJb
containers so that there is an instance of a given Entity bean for every
existing row in your table -- for large databases, this means that you need
to have lots of memory to hold all of these instances, and the time to
create all of these instances can be awfully long (not to mention the
overhead of managing all of these after they are loaded). EJB container
products may implement Entity EJB management in different ways to mitigate
this problem, but it's still a problem.
Instead of using Entity EJBs, many (most?) applications with large
databases use Session EJBs which can query databases through one or more
methods. Basically, Session EJBs issue queries against a database, while
Entity EJBs have to represent every row. Unlike Entity EJBs, Session EJBs
do not have a primary key and they do not need to create an instance for
every row in the actual table or view.
Someday, when we have bazillion-byte memory in our handhelds, etc, the
Entity EJB memory and loading issue should not be a design factor.
Hope this helps. Anyone else have thoughts on this?
Jay Armstrong
[EMAIL PROTECTED]
At 01:14 PM 1/11/01 -0000, you wrote:
>Hi,
>
>Probably been asked before but I can't find it in archives.
>
>I have a legacy database with over 80 tables, most of them represent many
to
>many relationships (M:N) just with 2 or 3 foreign keys. I'm building a EJB
>layer on top and the initial load is proving to be a bit slow.
>
>An example of software and manufacturer, I want to store all manufacturers
>of the current software....
>software setEntityContext method:
> retrieve the home interfaces for software_manufacturer and manufacturer
>beans.
>
>ejbLoad method:
>1. run findBySoftware_Id on software_manufacturer bean, which returns a
>collection of software_id/manufacturer_id
>2. Iterate through collection.
> - On the manufacturer bean use findByPrimaryKey with manufacturer_id
>from step 1
> - add to local collection
>
>This method is great if there are one or two beans but we have thousands
and
>it takes ages to start up.
>
>I have changed all 1:M relationships to the object relationship methods
>detailed on the orionsupport site and it knocked minutes off the startup
>time. If I can do the same with M:N it would be great.
>
>Ideas would be appreciated.
>
>Thanks for your time,
>Tim.
>
>Tim Squires
>Wireless Data Services
>----------------------------------------
>It's not what you know, it's who you tell.
>
>
