Rajshekhar Paul

Ranch Hand
+ Follow
since Oct 17, 2006
Merit badge: grant badges
For More
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 Rajshekhar Paul

In the singleton section (4.8.3) of the ejb 3.1 specification it is stated like the following-

「4.8.3Transaction Semantics of Initialization and Destruction
PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transactional.
From the bean developer's view there is no client of a PostConstruct or PreDestroy method.
A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transaction
attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or NotSupported if the deployment descriptor is used to specify the transaction attribute).
Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct method is the same regardless of whether it is initialized eagerly at container startup time or as a side effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy methods can be defaulted.」

Can anyone please put some light about the necessity of container managed transaction only for singleton lifecycle callback methods. For stateless session beans nothing like the above takes place. So, why for singleton this is required.

An example in the answer will be highly appreciated.

P.S. I have seen the same issue raised with JBoss forum. Here is the link https://issues.jboss.org/browse/EJBTHREE-2070?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aworklog-tabpanel.
@Ankit
Yes, I know that when JVM goes short of memory, it'll try garbage collecting the objects. But I didn't know that you were talking about the GC process during the loop execution which might be another chance!
@Cristian
Why are you with the impression that the garbage collector will do it's job during the for loop execution?

Ankit Garg wrote:No that will not happen. The if condition will be false as gc will be false till now.



Suppose, the for loop has finished executing. Then following things will be executed in order.
1. x will be reinitialized with 0
2. gc will be reinitialized with true.
3. explicit GC call.

After the 3rd step, if JVM wants to free memory, it will run finalize() methods for the objects created. So, when for the first time JVM invokes finalize() for a Finalizer object, inside the method, first if block will be executed as gc is having the value true(as per step 2), which in turn will increment x(which is 0 as per step 1) to 1. So, the next if block will print true 1.

Correct me if I am totally in wrong direction.

N Pats wrote:So there is a reference to intObj existing until the end of the method call. Is my understanding correct?



Yes, your understanding is absolutely correct. Just to add that - if you would have declared nums ArrayList as a static class member instead, then the ArrayList object would have never become eligible for gc as long as the class is alive in the JVM!

Ankit Garg wrote:The loop has also finished so x will again be set to 0 and gc will be set to true.


But inside the first if block, x will be incremented. So, in the second if block, x will not be 0.
Thanks Ankit, for the reply. It was a good help!
Hiya Ranchers,

I was going through the chapter 7 in SCJP 6 K&B book.
However, I have some doubts regarding the hashCode() method.

As per my understanding, hashcodes are used prominently in collection classes like HashMap etc, hashcodes are used to perform search operations in such classes.
The book says that if I override equals() method in a class, I need to override the hashCode() method too!
I have modified the code snippet in page 552 of that book as the below one.

So, if I create two separate instances of the class HasHash both having same x value, they are said to be meaningfully equal according to the overridden equals() method.
But regardless of the instances, all of them will have same hashcode 1234. Now, how these two instances are going to behave if I put them in a HashMap which holds the HasHash object as the key and some string as the value?

- Whereas if I have a cast, I have to check the cast type with the reference first, to assert that it compiles:


You need to take care of the thing that the reference/object type in the left side and reference/object type in the right side, fall into the same
inheritance tree. If they don't, code will not compile!

B b1 = (B)a; // the (B) on the richt is-a B of the left side, so it compiles, but at runtime, the object type must be checked:


Yoy need to check the object types during coding time only, unless it's gonna produce a runtime exception!
IS-A test always checks if the object in the right side is assignable to the reference type in the left side or not.
To test the assignable part, you need to first check if both the types fall in same inheritance tree or not and if they fall,
check if the type in right side appears down in the inheritance tree than type in the left side.

Hope the above explanation helps.

In between package and import statements, no other statement can appear.
And this whole compilation unit is wrong. A compilation unit can have only one public class.
I guess those values are just dummy values. They may be any value in place of 2 & 4, might be 10 & 11 or 57 & 58.
The main objective remains in testing your knowledge about the current thread.

In some question you may see the result being 2 2 4 4.
Suppose the thread ID for main thread and the new thread t1 are 4 & 2 respectively.
Now, with the above answer, you can say that after t1 thread is executed, main thread got another chance to run.

The values hardly matter here as they are JVM dependent(I guess), but the examiner wants to test the pattern in which they be printed.

Hope the explanation helps.
Again a silly mistake from my side.
Anyway, thanks again!
I have one more doubt.
Suppose the code is working fine with wait() and notifyAll() methods being called at name object.
So, in such cases, when the program is run, is there any possiblity that sometimes, the output will have A is notified?

I tempt to think so because, when ThreadA starts first, it will go to wait only to be notified by ThreadB. In that case, the output will be
Inside A
Inside B
Notify
A is notified
Thank you, Punit for the quick reply.
You corrected my misconception.