This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Journey To Enterprise Agility and have Daryl Kulak & Hong Li on-line!
See this thread for details.
Win a copy of The Journey To Enterprise Agility this week in the Agile and Other Processes forum! And see the welcome thread for 20% off.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

SessionBean - DAO, CMT and Tables with relations  RSS feed

 
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 ]
 
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.
 
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!