hi Dan
thanks allot for the design suggestions. They have really helped in my
design decisions. I have narrow the solution down to one of three. And this
one is one of them and I am thinking it is the best one.
also, this a observation of my system I for got to mention.
Probably 90% of images and text will NOT be shared across content although
they all can be. Generally when a new content is created new assets will be
created for it. (assets are images or text).
But when updates are done to assets that are shared, ideally they should be
seen straight away.
These are the potentials:
(when I refer to assets I mean images or text)
1) All independent entities in the system are modeled as Entity Bean (same
as your model).
advantages:
Simpler model
Updates to image and text are seen immediately from the Content Entity Bean
Things are cached (so will be better performance potentially)
The content ejb is easier to create (e.g. creation of text and image is
passed to relevant EB)
All database changes are done through entity beans (allot cleaner)
disadvantages.
More remote calls involves (e.g. from content EB to image or text EB) What
is the ratio of performance hits of a remote call to accessing the DB, which
is more expensive ?
2) I put images and text entities as attributes of content and use a cache
that times out.
advantages:
eliminates remote calls because image and text entity beans don't exist.
Things are cached (so will be better performance potentially)
disadvantages:
if an image or text is update independently of an entity bean the updates
are not seen in the other entity beans until the cache times out.
Database changes are split between entity beans and session beans for
updating assets
2) I put images and text entities as attributes of content and turn off
caching so the ejbload is called on each business method. (although I tweak
it so that ejbLoad() is only called via ejbFind- methods)
advantages:
Updates to image and text are seen immediately from the Content Entity Bean
(because there is no cache)
disadvantage:
complex model
no cache used (every time I find a content ejb it does an ejbload)
Database changes are split between entity beans and session beans for
updating assets
so it looks like the all entity bean solution is best. Well I am going to
build some prototypes of each and run some test. Thanks for your help Dan.
-----Original Message-----
From: Dan Davison [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2000 7:55 PM
To: [EMAIL PROTECTED]
Subject: Re: Invalidating an Entity bean
Peter,
The best way I believe is to model it as you would any Object Oriented
problem
That means do the best simplest Object Design and then tune it for
performance.
I would do the following
Content contains Collection of Images
Content contains Collection of Text
Content is an Entity Bean
Image is an Entity Bean
Text is an Entity Bean.
CONTENT is a TABLE
CONTENT_IMAGE_MAP is a TABLE containing the Content to Images mappings a row
per Content to Image relationship
CONTENT_TEXT_MAP is a TABLE containing the Content to Text mappings a row
per Content to Text relationship
IMAGE is a TABLE
TEXT is a TABLE
The thing you got to remember is that the only thing that will be read when
you load the Content object is the Content object itself and the primary
keys of the Images and Text is references.
If you reference the Images via a Content.getImages then you would call the
"Collection Image.findForContent(ContentPrimaryKey)" for each of those
images a single SQL call. via lazy instanciation
public class ContentEJB implements EntityBean
{
...
public Collection getImages()
if ( images == null )
try {
ImageHome imageHome = //jndi lookup and narrow
images = imageHome.findByContent( this.getPrimaryKey ) ;
} catch (Exception x) {
throw new EJBException(x);
}
//we are returning a collection of Remote objects to the Image
Entity Bean
return images;
}
...
}
public class ImageEJB implements EntityBean
{
...
public Collection findByContent( ContentPrimaryKey contentKey ) {
//SQL into the CONTENT_IMAGE_MAP Table
//return collection of image primary keys that the container turns into
Remote objects to the Image Entity Bean
}
...
}
public interface ImageHome implements EJBHome {
public Collection findByContent( ContentPrimaryKey contentKey );
}
Now comes the interesting part. Each one of the Image Objects can be
accessed individually. That means that you still have not loaded the images
until the ejbLoad for that ImageBean is called. when it is called it will be
cached.
So lets say you have another Content that accesses the same ImageBean. It
may need to access it and it is cached already as well. So you don't do
another read.
The same may be said for the text.
There are various caching strategies on different servers but if you are
lucky and your Image and or Text are read only objects. Then you can have
them cached indefinatly, and by playing with your caching sizes can get
optimum performance. If they are read only which by definition would only
have an ejbCreate and getter methods without setters and or ejbRemove and
ejbStore is not called then you are in very good shape.
This actually may be the "best" performing scenario regardless of the bean
granularity if it isn't then you have done the simplest thing and can look
for ways to tune your application later, or scale the application with
clustering and/or hardware.
The best case scenario for reading a ContentBean is 3 database calls. The
worst is 3+ Number of Images + Number of Text. The trick is to make the best
case happen the most.
In a single server environment where the database is not shared then you can
assume that all objects are cachable and ejbLoad is only called once.
If you write something complex in your initial design when you do not know
the performance characteristics is a bad idea IMO. I have had a similar
design consideration in my last EJB project. Making physically shared data
by Entity Beans into Entity Beans themselves solves the issue in the most
elegant way and has an easy scalability solution. I don't buy the
granularity argument on face value alone. I need proof that I cannot solve
the problem elegantly. If you do something complex you run the risk of
making a booboo on the scalability front.
Good Luck
Dan D
-----Original Message-----
From: A mailing list for Java(tm) 2 Platform, Enterprise Edition
[mailto:[EMAIL PROTECTED]]On Behalf Of Peter Delahunty
Sent: Thursday, October 12, 2000 11:26 AM
To: [EMAIL PROTECTED]
Subject: Re: Invalidating an Entity bean
the situation is this.
this is the current data model
I have and entity bean called "Content" this repsents 1 row in a table
called "content". The content enitity bean can have N number of images
(corresponds to n number of rows in the images table) and N number of text
blocks (corresponds to n number of rows in the text table).
However images and text blocks are independent of content. Content is only a
grouping of these assets if you like. So we get a many to many relationship.
1 content can reference many images
1 image can be referenced by many content.
(same for text)
so when a content entity bean loads up it loads into its attributes all the
data from the images and text that it references. So lets assume all this
data is now in a cache.
if i then change the data in an image or text independently of the entity
bean (perhaps by a session bean) then the data that is cached in the entity
bean is dirty (does not match what is in the database). SO how do i notify
the entity bean to refresh it's self ?
....
Another model you hinted on was that Image and text could be enitity beans.
They are certainly independent enities (qualify as enities). However i
consider them to be too fine grained. For example text block could be as
small as "hello this is a sentance" which is just a small string and so
wrapping this small string in an entity bean seem way too much overhead. But
the flip side is it would so the cache problem.
the session bean would do updates via the image and text beans and so they
would always contain the correct data. And content would get the data from
the image and text entity bean each time. However if the content has 50 text
block and 50 images that is 100 calls (one to each of the entity beans that
represent this data), which as you see is a major overhead
Any thoughs on how i best model this.....
cheers
-----Original Message-----
From: Dan Davison [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2000 3:49 PM
To: [EMAIL PROTECTED]
Subject: Re: Invalidating an Entity bean
Sounds to me like you are making an argument for making your Entity Bean A,B
contain another Entity Bean that that contains C and D. This of course is
only a solution if you only access the database from you EJB application.
Each bean that uses the data from C and D would contain this new bean. I
like to use lazy instantiation for this one. Only loading the contained bean
when it is accessed. Every call that starts a new transaction on the bean
will call EJB load.
Dan D.
-----Original Message-----
From: A mailing list for Java(tm) 2 Platform, Enterprise Edition
[mailto:[EMAIL PROTECTED]]On Behalf Of Peter Delahunty
Sent: Thursday, October 12, 2000 7:02 AM
To: [EMAIL PROTECTED]
Subject: Invalidating an Entity bean
Hi gurus
How do I do this cleanly.
I have and Entity that has attributes A,B,C and D. These attributes are all
read from database tables.
A and B are read from Table 1
C and D are read from Table 2
So I have Entity Bean 1, this is loaded by the app server (perhaps by a
findByPrimaryKey) method. This means that Entity Bean 1 is now a cache of
the data in A,B,C and D.
However while this entity bean is in the cache, via a session bean I change
the data of C and D in table 2. This mean that Entity Bean 1 now has dirty
data. So the question is how do I force the Entity beans to do and EJB Load.
Also the data in C and D in table 2 may be shared by N number of entity
beans so I may need to refresh N number of Entity Beans depending on which
ones are in the cache.
I only want to call EJB load for Entity beans currently in the cache and of
these I only want to call ejb load for the ones that refer to the changed
data.
Cheers Peter
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff J2EE-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 J2EE-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 J2EE-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 J2EE-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".
