Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!

Jean-Luc Thirion

Greenhorn
+ Follow
since Jan 24, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jean-Luc Thirion

Hi ranchers,

I want to understand how JTA functions, especially:

1) I see a JTA implementation like a third-party service (or maybe independent server) to whom I tell to start/stop transaction (related to one or more DBs) for me. This service could even be called remotely (Like in the case of client initiated transaction in EJB). Is the analogy right ?

2) I take on another analogy: when I use an SQL client like sqlplus/Toad etc. I always have to commit on a particular connection, the connection I opened. So transaction delimitation is done by sending orders (commit/roolback) on the db connection. The same is the case when I use JDBC directly, I call connection.commit(). Must JTA - behind the scenes - also commit/rollback on one (ore more) connections ? Or is it totally different (sending start/stop on XAConnection is similar to me)

3) In a J2EE server, we retrieve a UserTransaction object an a DataSource object separately. We retrieve a Connection from the DataSource and delimit transactions by calling begin/commit/rollback on a totally different object: the UserTransaction instance. Behind the scenes, the TransactionManager will have to commit the work done on the Connection object I retrieved. How does the Transaction Manager know that I delimited the work on that Connection (i retrieved the 2 objects totally independently), i.e. how does the Transaction Manager link the Transaction with the Connection ? Is it because, behind the scenes, both the Connection object and the "Transaction" object are associated to the current Thread ? If Yes, and if I call EJB2 from EJB1 through local interfaces in a same transaction, does that mean that the call from EJB1 and then EJB2 have to run in the same thread ?

4) In the case of a client initiated transaction (in the EJB world), I can start a transaction from the client by using a Connection (issued from a DataSource I got through JNDI at location A) and a UserTransaction(I got also through JNDI but at location B). How does the JTA Transaction service know that it should send "delimitation" orders to the DB on the TCP DB Connection the server holds for my client app ? Remember that I got the UserTransaction and DataSource apparently with no relationship together ?

I have a lot of ideas how that could be done behing the scenes, but I want to know how a typical JTA service must/does this ?


Thanks in advance for your replies,

Regards,

Jean-Luc

Reza Rahman wrote:Jean-Luc,

I am interested in developing an EJB 3 implementation as well (time has been my biggest problem for this). If you are serious about this, send me an email at reza_rahman@lycos.com.

Best regards,
Reza



Reza, thanks for your answer but like I said in my first post, I don't want to implement the spec. I just want to get a deep understanding of things and know how it is possible to write efficient implementations of the spec.

If you start an implementation, I will be very interested at looking each piece of code and maybe more. ;)

Best regards,

Jean-Luc
Hi,

I always thought that a business method call from a bean A on the local interface of a bean B was done in the same Thread as the execution of the method in B ? Probably that it is so in most server implementations, but is that required by the specification ? I think that the contrary would make server code and transaction management much harder...

Thanks in Advance for your responses...

More over in a previous post in an another topic I posted the way I would implement EJB in order to achieve scalability and fail-over with beans (things I know are NOT guaranteed by the spec). Is that realistic ? (Note: I don't want to implement a Server, just to get an idea of realistic implementations).

Please look here for my previous (maybe stupid) post: https://coderanch.com/t/422565/EJB-Other-Java-EE-Technologies/EJB-Tx-Exception-questions#1865164
Thanks Raf for your detailed answers !

For point 4, aren't stubs a scalability problem ? For instance, imagine this situation:


If I:
1- get a stub linked to a stateless bean S in "EJB Server 1"
2- then Server 1 crashes and the balancer knows that,
3 - then I call a method on S.

Will i get an Exception, or can the method transparently be redirected to "EJB Server 2" ? I think it is possible if implementing the "EJB Object" and "Stub class" appropriately (so the vendor should care). But would that be compatible with the EJB spec ?

On example of what could be a server-vendor implementation that enables this behavior:

Stateless beans: To implement that we need first not to create a specific "EJB Object" for each client (because if we do that each subsequent requests on will have to be redirected to that specific EJBobject that lives on this specific server). So we need that the server creates - at startup time - one big "EJB Object for all stateless beans of type X" on each server. Then the returned stubs will need to have things like a "Client UUID, and the Virtual IP" .



Remote Entity beans: Same could be done as for entity beans. Each server has a big "one EJB Object for all beans of type X" , but the returned stubs have to know the primary key of the entity they are accessing, and the Virtual IP. For instance, if the client calls: entityAccount.setAmount(10); and that entityAccount has the pk #3000, the stub will send something equivalent to "call on VirualIPs EJBObject method entityAccoount.SetAmoun(#3000,10)", and each "big ejb object" on each server will know what to do: "take an entity bean, load it with Account #3000, ejbLoad, and then call method "setAmount(10) on the loaded bean"


Statefull bean: Not possible because the state of the bean lives on server1. So this will require complex "bean state" sync between the servers.

[ January 03, 2009: Message edited by: Jean-Luc Thirion ]

[ January 03, 2009: Message edited by: Jean-Luc Thirion ]

[ January 03, 2009: Message edited by: Jean-Luc Thirion ]
[ January 03, 2009: Message edited by: Jean-Luc Thirion ]
Hi Ranchers,

i have a few questions about Exceptions and "Container Managed Transactions", note that I have a good idea about the answers but I hope precise and convincing answers. Thanks in Advance Ranchers!

1) An ApplicationException (CreateException, NotEnaughMoneyInAccount, FinderException...) thrown by a bean does not rollback the transaction , Why ? For instance, if the transaction was started by a stateless session bean "S" and if "S" throws an ApplicationException, why should I want to commit the transaction. Moreover, that means also that if a client of an entity bean receives a CreateException, the client has no idea if the database insert was successful. Too bad, isn't it ?

2) What is the need for setRollbackOnly if I want the running transaction to rollback ? Why not just throwing a SystemException (that will cause an automatic rollback) . Moreover, instead of relying on the other beans checking the "rollback only flag" with getRollbackOnly to avoid lenghty tasks, is throwing a SystemExcption not easier ? (OK! One argument against throwing a SysEx is that beans state may become corrupted, but an Entity Bean will resync with the DB at next method call, and a stateless bean will be reset, so this affects only Stateful beans ? Right ?)

3) When do I need SessionSynchronization and what would I want to put in afterBegin, beforeCompletion, afterCompletion (Tell me a use case please). Only Stateful session beans should need afterCompletion, in order to leave the bean in a clean state for the client when he calls the next method ?

4) Other question not about transactions but a general purpose question. With the "remote call procedure paradigm" i always have to get a "stub reference" to an object in order to call a method ? Is that not a performance problem?

I know my questions are a bit long.
Thank you if you read so far.

[ January 02, 2009: Message edited by: Jean-Luc Thirion ]
[ January 02, 2009: Message edited by: Jean-Luc Thirion ]
Hello ranchers,

I have the "Head First EJB Book" and I want to follow it in order to learn on EJB 2. But to follow the instructions I need the J2EE RI and maybe Java 1.4 or 1.3 (Which are quite old).

Where can I find that ? I didn't fount J2EE RI downloads on Sun's site...
What's the best replacement ?

Which EJB container do you suggest to follow the book ?

Thanks in Advance for your help


EDIT: OK, I found that https://coderanch.com/t/163093/java-EJB-SCBCD/certification/Head-First-Setup-Document-Windows. Can someone guaranty that it is not outdated?
[ November 29, 2008: Message edited by: Jean-Luc Thirion ]
For method-local inner classes, only "compile time constants" are available. a is final and initialized at declaration, so the compiler knows it at compile time.

b is a normal, stack variable, and is not a "compile time constant". Think at it, outside of the method b will disapear (out of scope). An instance of the internal class could be linked to another object whose lifetime is much much longer,for instance:


After call of m1(list). List will stay alive and be filled with an object of type Outer.Inner, which will have a reference to b who may be garbage collected
Does that imply that the combination "boxing + Object Widening" is ok also for assignement ?

For instance, I think this will compile (I am quite sure):



Sorry, I know I can test that but I am not at home right now.
[ October 22, 2008: Message edited by: Jean-Luc Thirion ]
I added an errata to my initial post for p731 of K&B.

shoud be : It will NOT go ...
I think the question is not clear enough.

Since the "notify" call should be in a synchronized block, like this:

Other thread than A, say T:

At point //2 , thread A is notified but has to acquire the lock on B. Unlike wait(), notify() does not release any lock. So Thread A gets a chance to run only at point //3 where the lock is released.

If I am right I think this question needs further clarifications in the K&B's book. Maybe I should then add the tag [Errata] or something like this to my post in order to draw attention to my post ?
In Question 10 from Chapter 9 of K&B's book, the answer is A. I would have answered A and B. Can you explain why B is not correct ?

Question 10 page 750:

Assume the following method is properly synchronized and called from a thread A on an object B:

After calling this method, when will the thread A become a candidate to get another turn
at the CPU?
A. After object B is notified, or after two seconds.
B. After the lock on B is released, or after two seconds.
C. Two seconds after object B is notified.
D. Two seconds after lock B is released.

Also I think the is a mistake at page 731 where it's written:

The sentence should be: "it will NOT go"


Thanks in Advance for your help.
[ March 17, 2008: Message edited by: Jean-Luc Thirion ]
Ok...
One thing you can't do without wildcards:


So... "List<Dog>� IS-A "List<? extends Serializable>"

Source: today.java.net
[ February 07, 2008: Message edited by: Jean-Luc Thirion ]
13 years ago
Ok the answer to my previous post is: There is NO DIFFERENCE
i.e.:
- The compilers checks are the same
- The generated bytecode is the same


I compiled this piece of code:


Now
1�) If i decompile the bytecode with jad, I get the exact same code,
i.e, there is no difference after type erasure:

That proves there is no difference at runtime (it was quite obvious because of type erasure)

2�) Now a comile time. If I uncomment line #1
the code does not compile anymore, and I get the error:


if I comment line #1 and I uncomment line #3, the compiler prevents me from doing that and I get the following compiler error (which is very similar to the previous one):


If I re-comment the lines marked #1 and #3, and I uncomment the lines marked #2 and #4, the code compiles and runs fine.


As a first conclusion, I don't see a difference between both declarations because the behaviour is similar at both, compile-time and runtime. So I really don't understand the need of the <?> symbol in the language. Please tell me !
13 years ago
So what's the difference between:


and


Is the second declaration not legal ? (I will try it later when i can do it)
13 years ago
Hello,

why has the symbol <?> be added to Java 1.5 (for generics)

Given that scenario (extracted from K&B's book):


But it seems to me that the checkupAll implementation could be replaced by:

In this second implementation of "checkAll" is the List also read-only (probably it is)?

So what is the need for the <?> symbol in the language? I don't totally understand.

Thanks in advance for your help!
13 years ago