Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

one entity bean for entire database

 
Dieter Cailliau
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hey guru
i have made a very interesting entity bean but i'm a little unsure if it is allright what i'm doing (when it comes to transactions and threading). Therefore i would appreciate it very much if you could give your opinion on it.
topic on the serverside
thanks!
dieter cailliau
 
Steve Chernyak
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Based on this thread:
http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t=002293
I would think that the approach would result in very poor performance, since you would have one client that locks the hole database. Or am I missing something?
SteveC
 
Ruilin Yang
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It the database is big, the disadvantages are:
1) when you do transaction, the whole database is locked.
2) If the database is big, the caching the entity bean will take a lots memory.
3) object-relation mapping can be complex.
If your database is very small that may not be a bad practice.
 
Dieter Cailliau
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm very unsure about entity beans and simultaneous threads.
I read everywhere: entity beans are multi threaded. So i believe that many clients access my database together. I don't see why client B can not enter my entity bean when another client is using it.
I hope when it comes to transactions, that only the database is used to let it work. For example, every client is allowed to do stuff in it's own transaction, and it's the database who decides when the concurrency became too much to handle.
Anyway. I may test it one day because these issues are not clear. If it does not work, what could be a good alternative? Stateless session? The problem is, i need, for each database i use, a specific instance (of my persistency object which is now wrapped into the entity bean). The details of those database (structure) is the same, only the name (datasource) differs.
I can not deploy twice one bean with different env parameters on one computer. Does not work. It's useless to make statefull session beans because there's no state per client, but state per database. I could make for each database one statefull bean and put it public, like in the app context, and let many clients use the same statefull bean, but i think it wont work because the container will dispatch those concurrent calls to many instances.
If re-entrant is what they say in that thread, has j2ee a setting to express what i mean?
 
Matjaz Juric
Author
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dieter,
Please look at my answer in “This weeks Giveaway”:
http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t=002280
 
Dieter Cailliau
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The answer above said: not the j2ee container but the dbms looks after handling concurrent transactions.
Depending on optimistic or pessimistic locking, and transaction isolation level, the concurrency will be better or worse.
The reason why the container can not manage the transaction concurrency (meaning for example: let the last client wait until the previous returns before it may enter the ejb) is, that the container does not know when a thread (client) writes into an ejb (you don't have to specify "write" flags in your deployment).
So an entity bean is multi threaded even if each method is transactional. The transaction is the responsability of the dbms.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic