Dieter Cailliau

I have made a filter that post-processes my jsp output, but for some reason, this makes the browser wait for more data, while there is no more data. It's progress indicator shows it's still loading, even if there is no more data to receive. The onload-event is triggered very late. It's like the filter tells the browser the response is longer than it send data.
kewl graemlins :roll: happy joy

This is the problem:
there is no use in saving the key-connection mapping in a stateless ejb: why is it necessairy to assure that one client receives the same connection, if the ejb is designed stateless? Stateless means there can be no relation between subsequent calls, of any kind.
If it is needed to remember the right connection for the right client, you have to use a statefull session bean. The connection would be created when the session ejb is created, and closed when the session bean is removed. If your client holds a reference to its statefull session bean, then the same connection will be used for that client, evrey time he calls a method.
If it is not required to give the same connection, you have to acquire the connection in the beginning of the method and close it in the end of the method.
I think a statfull session bean that does not release it's connection during it's entire life, is the worst scalable design you can create in ejb: not a good idea. Of course, in eai, sometimes you have no choice.

sun's reference implementation container throws a corba exception when i try to return a DefaultMutableTreeModel from an ejb.
Can anyone tell me what i can do about it?

kewl!

dear Matjaz
i still don't get it.
non-re-entrant (=default) means:
"a container can prevent illegal concurrent calls from clients."
Which concurrent calls are illegal?
I thought entity beans were multi threaded!
Last paragraph: do you mean a loopback is illegal, unless re-entrant is specified? Then my original question still is: why did the j2ee inventors made this a special case in the first place? What is so specific to a loopback that it needs special treatment?
You also say: "The container however cannot distinguish from a loopback and concurrent call from a different client." If so, why is the explanation (specs) of "re-entrant" only about loopbacks, and not about concurrent clients? If the container can not distingush those?
come one Matjaz, enlighten me!

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.

Why is an ejb non-re-entrant by default? What's the good thing about this restriction? I don't see the point, i would never have thought about "hey maybe we could provide a mechanism that disallows ejb A to call back itself with another ejb in between". So what?

dear matjaz
thanks for your reply. You're not the first to point me to the meaning of re-entrant. I slowly begin to understand it is certainly not what i hoped that it would be. Though i wonder what it's good for, that a bean is non re-entrant in the first place.
If you're still round, maybe go back to the thread with my question, there's more explanation added. Where i really need an answer is: what happens if one entity bean (with pk "12") is accessed by two clients, and all it's methods are transaction required. Are two threads going toghether over the bean, and is the transaction enforced in the database by the database mechanisms, or is it the j2ee container who denies access to the second thread because it knows the first thread is in transaction?
(the thread + extra info)

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?

Hi Matjaz,
a question for really clever guys like you must be one:
question is a topic itself
(i'm sorry for the forwarding, but as a programmer i can not duplicate a question on many places)

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