• Post Reply Bookmark Topic Watch Topic
  • New Topic

SessionBean - DAO, CMT and Tables with relations  RSS feed

 
Morten Franorge
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a DB/domain structure that translates into something like this:
One person may have 0 or more telephone numbers
One business may have 0 or more telephone numbers
The telephone numbers are stored in one table, the business in one, and the person in one.

I would like to persist the person by having a PersonDAO and the Business by having a BusinessDAO. The DAOs would call a shared TelephoneNumberDAO to persist (calling a update method, that will delete, insert or update based on a flag in the telephone-object) their ArrayList of telephoneNumbers.

If something goes wrong during the update (of either telephone number or business/person) the transaction should be marked for rollback by the session bean (using CMT, accessing the sessionContext).

So I guess the code would be something like this:
in the PersonSessionBean:


PersonDAO


I guess my question is whether this design is ok? The session bean handles the transaction (rollbacks). Should the session bean or the DAO be responsible of looking up the datasource/connection?
[ January 10, 2006: Message edited by: Morten Fra Norge ]
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As the DAO implements the persistent layer, then the DAO will obtain the DataSource and Connection.

I recommend caching the DataSource in a static variable.

Another thing: it looks as if PersonException is a checked exception. I would override its constructor to accept the reason for the problem, eg SQLException.
 
Morten Franorge
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Roger Chung-Wee:
As the DAO implements the persistent layer, then the DAO will obtain the DataSource and Connection.

I recommend caching the DataSource in a static variable.

Another thing: it looks as if PersonException is a checked exception. I would override its constructor to accept the reason for the problem, eg SQLException.


Thanks, the exception already takes the reason. I have just simplified things making up an example myself instead of including the complicated code. The example shows what I am trying to do in a simpler matter.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Roger Chung-Wee:
I recommend caching the DataSource in a static variable.


Are data sources guaranteed to support multi-threaded access to them? I'm pretty sure is that the answer is "no". The EJB spec makes it pretty clear that statics are not healthy to use with EJB components because you aren't supposed to deal with thread safety yourself, which means that anything used by an EJB component (like a DAO class) has similar issues.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem that the EJB spec seeks to address is static variables which can be altered, causing potential problems should bean instances get distributed across different JVMs. This is why these variables should be declared final.

However, the DataSource is obtained only once because only one fake name is needed by the Bean Provider. So, it is read-only. All that is needed is for the getDataSource() method to check whether the DataSource variable is null and obtain the ds if needed. Once cached, its reference can be returned on each request. This should work in a distributed environment.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!