Henry Wong

Campbell Ritchie wrote:You asked about locks a few weeks ago

Agreed... https://coderanch.com/t/698053/java/ReentrantLocks-Java

Henry

Vaibhav Gargs wrote:If we make all the methods as synchronized, then, won't it solve the purpose?

Synchronized is a tool. A tool that will enable calls to be atomic. Atomic calls does not mean thread safe.

It is not a magic bullet. You have to use correctly. Multiple calls on the ArrayList, multiple calls on the elements. etc. have to be taken care of. Thread safety is not a fire and forget thing. It has to be part of your application design, etc.

Henry

Order of evaluation is left to right, regardless of precedence / associativity.

See section 15.7 of the Java Language Specification... https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.7

Henry

This is not hypothetical. This is true with all messaging systems. The (durable) subscriber is always responsible for duplicate detection.

Think about it. The broker delivers the message to the subscriber. The subscriber (along with the whole client application) dies. Then the subscriber comes back (when the application is restarted)... did the subscriber get the message? and if so, did the subscriber processed it? and if so, did it process it to completion?

The messaging environment always choose to resend under these edge conditions -- meaning it will choose to guarantee the delivery over avoiding duplicates.

Henry

PS... Yes, XA transactions would help here, but keep in mind, this is not in common usage -- and not many messaging environments support them.

When the compiler tells you that it can't find a symbol, it tells you what it can't find. What symbol can't be found? And are they present?

Henry

Atul More wrote:
By using the Read and Write lock mechanism, the only thing I want to understand is, how DB operation we manage like account debit/credit. Multiple threads reading the value and writing as well.

Keep in mind that a reader writer lock is designed to be used cooperatively. It doesn't actually prevent any access to data.

Only one thread can have write access to the RW lock (with no other threads having any access). Many threads can have read access to the RW lock (with no thread having write access). As long as the threads having read access only using the data in a read only manner, and thread having write access allowed to change the data it should be fine. If the threads access the data without the correct access to the lock, it will still be allowed. It is your responsibly to make sure you access the data correctly.

Henry

Paul Clapham wrote:
Or if you just have a specific list of classes you're interested in here, let's bring up the idea of making those classes implement a specific interface again.

I am going to speculate that the OP is trying to change fields from a third party library. And changing interfaces (API) is probably not an option here.

Henry

Fred Victa wrote:
Suppose the properties are private. If the field is of type Date or Calendar and it is not null, how can I convert the timestamp to UTC?

The java.lang.reflect.Field object has setters. So, you can set the value of the field too.

However, keep in mind, you will need permission. If there is a security manager, and your application don't have the rights, the operation will fail (also you can request access to private fields via the setAccessible() method call too, which can also fail if the security manager doesn't allow it).

Henry

The nextInt() reads a token and converts it to integer. The nextLine() reads from the current position to the end of line. So... when you type 38 followed by a CR, the nextInt() will read the 38, and nextLine() will read the empty string between the 38 and the CR.

Henry

Darya Naghiyev wrote:
why if  condition return false ?
but
if ( a.equals("derya")) System.out.println("equals");
return true  // it is understandable after your explanation

The == operator is doing an identity comparison. It is true only if it is the exact same object -- and it is not. The equal() method is doing a value comparison. It is true, if they are both the same type, and has the same value.


To compound the confusion, your algorithm is affected by the string pool, and compile time constant optimizations. Basically, the concatenation express (the way you have it in your example) isn't a compile time constant, and hence, a new object is created as a result. And this object is not the same as the one in the string pool.

Bottom line... use the equals() method. There are very little cases when you need an identity comparison of strings.

Henry

Vaibhav Gargs wrote:I just noticed there is something known as UncaughtExceptionHandler, will it work in this case?

The UncaughtExceptionHandler will run your code in the same thread at the task that thrown the exception. So, in this case, you still need to get the exception to the other thread. If you do that, then sure, it will work.

Vaibhav Gargs wrote:Using ExcecutorService, how the exception handling will be managed - any specific method/feature and say i have submitted 10 tasks in executor service, and task # 3 throws an exception, what will be the impact on other threads?

The theads managed by the executor service (ie. thread pool) will catch all throwables from your task, and place them in the future object for later retrieval. After that, the task is complete. It will not have any lasting effects on any other tasks, or any threads in the pool.

Henry

Vaibhav Gargs wrote:Thanks Henry. How to handle such situations?

I would recommend using an ExecutorService (specifically, a threadpool) instead of creating your own threads. In that case, the Executor will save the exceptions thrown, and provided it to the other thread as part of the result via the Future object.

Henry

Ryan McGuire wrote:
'nuff said.

Hee Hee. Only a fellow trainer would understand the significant of those numbers....

Too bad there are very little reasons to friend a trainer that you will never battle, raid, or trade with... or I would send an invite.

Henry

Threads are independent of each other -- each with there own call stacks. Heck, by the time the exception is thrown, the try block of the main thread could have long completed. It would also be silly to tie these threads together, as you will lose the parallelism.

Henry

Vaibhav Gargs wrote:
How does CMS achieve high responsiveness and Parallel GC achieves high throughput?

The Parallel GC is ... well... parallel. It can use multiple cores / processors. This means that on a 8 core machine, it can (in theory) collect about 8 times more garbage per time than a single threaded (non parallel) GC. This can achieve much higher throughput than a single threaded GC.

On the other hand, the parallel GC is a "stop the world" collector. The application has to wait until the GC task has been completed. The application doesn't run during a parallel GC.

The Concurrent Mark Sweep collector is ... well... a concurrent collector. It is not stop the world. Granted, it is single threaded, so it doesn't collect at a high rate. However, the application does run during GC. Only the threads that are waiting for memory have to wait -- and they only wait until the memory is available. This can achieve higher responsiveness.

Henry