Shouvik Bhattacharya

Ranch Hand
+ Follow
since Jul 13, 2014
Shouvik likes ...
Eclipse IDE Java
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Shouvik Bhattacharya

I was a bit sceptical while asking this question, I thought maybe I was asking something way to simple to understand. But now I feel elated having asked this question. There was a lot to learn from it. I am really thankful to this wonderful community.
Cheers! and thank you for sharing some wonderful knowledge.
4 years ago

Stephan van Hulst wrote:

  • don't call methods of the current class unless they are private, final or static
  • don't start new threads, and

  • Can you please elaborate a bit on this why this is so.
    4 years ago

    Dave Tolls wrote:The object exists before the constructor is executed, with default values for its attributes (0's, null's, false).

    Unless the constructor finishes its execution how can it exist?
    4 years ago
    In snippet below is the use of 'this' acceptable.

    How is 'this' available inside the constructor when the object represented by it is yet not constructed?
    4 years ago

    Tushar Goel wrote:ApplicationContext creates an instance of beans per container if scope is singleton. It is also default scope.

    I am aware of this however this is not exactly what I am looking for
    5 years ago
    Hi Guys...I found something new (probably because I never saw anything like this before ) and was googling for some explanation without any luck.

    How many instances of Student bean gets created ? I thought probably a singleton bean will eventually get created, irrespective of the number of definition for all the same type of beans, spring container would return the same singleton instance. But, I guess ApplicationContext is creating a singleton instance per bean definition in the spring container instead of a singleton instance per container? Am I doing something wrong?
    5 years ago

    Karthik Shiraly wrote:It's useful when you want Spring to auto scan the classpath and find those configuration beans by itself, instead of explicitly registering them in code.

    If I have understood it correctly then by auto-scan you mean beans discovered via @ComponentScan and when your are saying explicitly registering them in code you referring to the way I have done it in file? I shall appreciate if you can explain with a code snippet.

    5 years ago

    When writing java based configuration in Spring is @Configuration optional because:

    and then this

    It seems that the spring container is fine with creating the beans even if I happen to remove @Configuration from the file. If that is the case then what is the use of it?
    5 years ago

    Henry Wong wrote:However, this won't work. The way that it is coded, there can only be one SharedRes instance -- it must be a singleton.

  • Okay.. I think I get this, since I am creating only a single instance of the SharedRes class in the main method you are suggesting it is better to change sharedRes to a singleton class instead of creating an instance. This, I suppose would look pretty neat from a design standpoint. I hope I have understood correctly?

  • Henry Wong wrote:Your SharedRes class methods takes a SharedRes instance. I am assuming that this is done in order to support more than one SharedRes instance, meaning having more than one separate groups of producers and consumers working independently. Otherwise, why do this?

  • Can you help me with a use case or an example where such a situation might come up. The only bit of thing I could come up with was where maybe one group of producer-consumer operate on a given state of the SharedRes class and the other group can start operating on SharedRes only after it achieves a state intended for the other group to work with. I could be wrong though...

  • Thanks
    Hey thanks Henry... I wasn't aware of that. This discussion has been a great learning experience. So, I hope the last code I posted should be fine with respect to your previous suggestions?

    Campbell Ritchie wrote:
    What are the changes you made? Please explain what you are doing.

    I was studying about inter-thread communication and as we are already aware that threads communicate amongst each other via wait and notify methods by securing a lock on the appropriate object. This is absolutely fine when one is working with instance methods as these are non static contexts and facilitate the developer to invoke the wait as well as the notify methods but lets take a use case where a communication has to be established between a static method and a non static method i.e. a class property and the other being an instance property. As far as the instance method is concerned it is fairly easy to invoke the wait and notify method but when talking about a static method we need a workaround as the same is readily unachievable. Through this thread I intended to know if my use case is at all a valid one and whether I am working in the right direction, if the motivation is correct then I wanted to illustrate this mechanism. Now, in order to get a better view of the entire flow I would request that you follow the code that I wrote at the beginning and gradually progress through the discussion that I had with Henry where he pointed out where I was doing it wrong. I tried to incorporate his suggestions and hopefully have got it right this time, just waiting for a final confirmation from him.

    Hope that helps...

    Hi Henry....just made another round of changes based on the flaws you pointed out. I am posting the new changes would appreciate your feedback. Thanks:)

    Yup... I understand your point....but the following thing in quote was done deliberately on my part just have my appropriate understanding in place

    Winston Gutkowski wrote:
    Sounds about right, but you don't have to use:
    in either case.

    synchronized method would have worked as well.
    Hi Henry... After returning from the office I started debugging the previous code and accordingly carried out few changes. I just logged in to the ranch and walah! just read your reply which certainly corroborates my debugging efforts... Ya.. I made a silly mistake of not consuming the data to its entirety... So, now I am posting the changes I have done, would be great if you can point out the other flaws. And ya... just just to make sure we are on the same page I would like to reiterate the context that drove me to write the code in the first place which was that I wanted to have the threads communicate amongst each other between calls from a static method and a non static one as its kind of not possible to invoke wait or notify from a static context without some additional efforts. The code may not be a neat one but its working though

    Hey thanks Winston...really learnt some valuable stuff here as far as the lock part is concerned. I was kinda under the illusion that static is to Class Lock and instance is to Object Lock, well things can be taken that way but now I feel that if the context demands thread safety of your instance then its the instance under consideration upon which appropriate synchronization efforts should be carried out in order to protect instance related state and on similar grounds when talking about Class properties or in other words the static guys the context demands synchronization efforts on the Class to be made. In short we can say that there is a lock available its up to the developer to make sure that he understands the contexts needs and codes accordingly. Hopefully I have understood.