I originally sent this on Oct 11, but it never made it to the list
Hence I'm sending it again...
The architects at my company have come up with another creative plan which
I'd like to run by you folks.
Please tell me if you think this is a good idea:
Short Version:
Is there a reason to hold references to entity beans in a data structure in
memory?
Is there a reason to hold an organized collection of references to entity
beans in a data structure in memory?
Is there a reason NOT to do so?
Long Version:
We are building an EJB application which, among other things, allows users
to create and update schedules.
The events in the schedules are viewed and maintained
(created/updated/deleted) by a large group of individuals.
We represent events using a number of Entity Bean classes which implement
our Event interface.
We maintain these events using a number of Session Bean classes
(EventTypeAManager, EventTypeBManager etc)
We represent a schedule using a non-EJB wrapper class named Schedule which
holds a vector of Event Entity Beans (remote references). It provides
methods which allow the JSP to retrieve logical subsets of those Events
(Events of type A or B, Events grouped by a common attribute etc)
We then have a ScheduleManager Session Bean which provides functionality to
the JSP's such as
getScheduleForArea(areaKey, startDate, endDate)
getScheduleForPerson(personKey, startDate, endDate)
ORIGINALLY, we were going to simply put JDBC stored-procedure-calls in the
STATELESS ScheduleManager. These stored procs would retrieve the id and
EventType of the rows representing the requested events. We'd then
findByPrimaryKey each event, using the id (and the EventType to determine
which EntityBean class we'd need to instantiate), and pass back a Schedule
object.
The NEW CREATIVE PLAN is this:
Each user, after logging in, obtains an instance of a Stateful Session Bean
called UserSession. This UserSession instance will hold a STATEFUL
ScheduleManager. Each ScheduleManager keeps a vector of Event EntityBeans
(remote references) in memory. It keeps them in an object called a
Timeline.
The Timeline is a non-EJB wrapper class which holds a vector of all the
Event Entity Beans (remote references) (or, in another design, Event Entity
Bean keys) occuring between 2 dates and related to a given area or person.
This class, unlike the Schedule class, only provides methods which retrieve
time-related subsets of those Events (Events starting before x, Events
ending between X and Y, etc)
Thus, when the ScheduleManager is asked for a schedule, it first checks to
see if its TimeLine object holds Events whose dates span the date range
requested and whose Area/Person matches the Area or Person requested. If it
does, it asks the TimeLine for those events, creates a Schedule using those
events, and returns the schedule. If it doesn't, it creates the TimeLine
(via a JDBC call) and then proceeds as stated in the previous sentence.
For a while we were talking about using a Singleton class which would hand
out one instance of ScheduleManager for each Area/Person. That way, as the
events are updated/created/deleted, we could be sure to update the
appropriate TimeLines. (The Timelines of all Areas and People related to
that event) However, as I understand it, the Singleton pattern doesn't work
in EJB because there will be 1 Singleton per VM, in other words,at least 1
and maybe more, per container.
Hence, we've discarded the Singleton idea. (Side question: could we revive
this Singleton architecture idea?)
THE PROBLEM AS I SEE IT:
If someone removes an instance of a bean, we're going to have a null pointer
in the related Timelines' vector object.
If someone adds an instance of a bean, we're not going to know unless we
update the Timeline's vector object.
We seem to be duplicating effort already carried out by the container.
Opinions?
===========================================================================
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".
