File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes one entity bean for entire database Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "one entity bean for entire database" Watch "one entity bean for entire database" New topic

one entity bean for entire database

Dieter Cailliau

Joined: Jan 17, 2002
Posts: 11
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
dieter cailliau
Steve Chernyak
Ranch Hand

Joined: Oct 19, 2000
Posts: 113
Based on this thread:
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?
Ruilin Yang
Ranch Hand

Joined: Jan 06, 2002
Posts: 150
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

Joined: Jan 17, 2002
Posts: 11
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
Ranch Hand

Joined: Aug 02, 2001
Posts: 65
Please look at my answer in “This weeks Giveaway”:

Matjaz Juric<br />Author of <a href="" target="_blank" rel="nofollow">Professional J2EE EAI</a> and <a href="" target="_blank" rel="nofollow">Professional EJB</a>
Dieter Cailliau

Joined: Jan 17, 2002
Posts: 11
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.
I agree. Here's the link:
subject: one entity bean for entire database
It's not a secret anymore!