Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!

Rakesh K. Cherukuri

Ranch Hand
+ Follow
since Jun 01, 2010
Rakesh K. likes ...
Eclipse IDE Fedora Java
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
2
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rakesh K. Cherukuri

jboss 7.1.1
EJB 2.1


Hi,

Though it may seem strange but in one of the application i work on still uses EJB 2.1 entity beans.

While looking at the deployment log, seems like each Entity bean is registered using both remote-home and remote interfaces.

java:app/EJBApp/Entity!com.abc.remote.Remote
java:app/EJBApp/Entity!com.abc.remote.RemoteHome


Using the remote-home's JNDI lookup i was able to get the EJBObject proxy and subsequently create and use the entity.

But what about the remote interface JNDI lookup ? Reason i am asking is that one needs to create an entity before use it. That said, how to use the object that i get from remote interface JNDI lookup ? Note that the class of the returned object says its "com.sun.proxy.$Proxy13" type.

The JNDI location i am using "java:app/EJBApp/Entity!com.abc.remote.Remote"

- Rakesh

Regarding no interface client view, the spec says

A Session Bean’s no-interface view is a variation of the Local view that exposes the public methods of the bean class without the use of a separate business interface.


It also says

A client does not directly instantiate (use the new operator on) the bean class to acquire a reference to the no-interface view.


Googled it couple of times but couldn't find answer for "Is there a way to prevent client from using new operator ?"

Appreciate any comments.

Kate Jackson wrote:

I must have gotten the wrong end of the stick, but isn't the LINE 1 read the same scenario as here:

If one thread calls setValue() there is no guarantee that subsequent reads in other threads via getValue() will ever see that value
(taken from java-concurrency-bugs-5-inconsistent-synchronization)

This would mean that at least theoretically there's a chance that the getAllFoos() method will never return actual state of the foos.


I think there is one thing you are missing in your code. If you look closely, iterablefoos are read/modified within synchronized code (all 3 methods). The only exception is at line 19. There are two problems here
1. As you rightly said, you can see stale data which can be fixed by using volatile.
2. Even if you use volatile, as you are making a copy of the value while there is a chance that other threads can modify it by the time you use it in dispatchEvent(). Now As Henry rightly pointed out see if you agree that volatile is not going to solve the problem.

Henry Wong wrote:Second, just because something is volatile doesn't mean that it won't get stale. If your definition of stale is that it always need to be up to date, then what happens with the case where you load the reference, but before you use it (or finish using it), it gets changed. If that is your definition of stale, then volatile won't help -- you will need to grab the synchronize lock, and hold that lock until you finish processing the data.

Quick question: Is there a reason foos.toArray() is used instead of foos.iterator() ?

Coming to your questions:

Assuming same instance (of the code you posted) is used by multiple threads

1. I think it is still possible. One scenario i see is this. Thread1 is trying to read and is at line 27 i.e rc has some value. At the same time Thread2 is adding/removing a value and set the iterablefoos to null. In this case Thread1 will see invalid value as iterablefoos is set to null by another thread.
2. Volatile will not solve the issue. Reason, the issue is not related to memory read/write. Problem is the iterablefoos is modified at multiple places and
- getAllFoos() is returning the value which could have been modified by some other thread.
- dispatchEvent() is not using synchronization
3. Using local variable rc is a good thing to make sure there is no reordering problems.

Assuming every thread gets its own instance
1. No. No, it is guaranteed. The synchronization in getAllFoos() makes sure of happens-before of the change in iterablefoos
2. No volatile use is required.
3. No. Since synchronization is in place rc is not required

Open to discussion though.
There are many unknowns in your questions which potentially influence the solution you are looking for.

What you are trying to achieve seems to be this

1. User1 gets the list and is currently looking at. He/She still thinking what to do next
2. User2 also tries to get the list. But since the data needs action from user1, user2 is not even shown the list and has to wait.

In this scenario,

1. How do you know if user1 is DEFINITELY does the second action i.e. update log table ?
2. Even if user1 does the second action, is it allowed to block user2 till that time ?

My gut feeling is that you are far from thread related scenario and more into the database transactions. See if you can try something at transaction level and get help in that forum.
@Neeladyuti Chaudhury : More you are specific about your question better the chances you get a good response. Your post is very vague and people, who read it, cant even imagine what you are looking/asking for. Can you please rephrase the post to signify which part of it you want to understand ?
Based on the amount of data you are talking, i strongly feel its a classic example of ETL (extrct, transform, and load). Are you sure you want to handle it the java's way ?

Even though you think concurrency can make it faster, it all drills down to database capabilities too. I see that is where you are going to encounter problems going forward.

Just to get a brief idea, you can do following experiment

create two tables and populate say 1 lakh records into one of the table.
have one simple class that takes data from one table and populate into another
no need to use any synchronization
use straignt forward JDBC
since one or two connections are needed, no need to use pooling

That should get the idea of what we are going to get eventually.

If you have already done and very sure then

- reading the accounts is a straight forward way. Is your question about how to code it ?
- processing 100 (or some other number) depends on what your clients are looking for. that said a reasonable time can be arrived at after fine tuning your application
- for pooling you can use commons dbcp. That should do the needful.
From your description, the requirement looks something like this

1. The multithread utlity (lets call it that way for now), should accept the number of threads which is dynamic (i.e. one for each account)
2. Each task will operate on one account and take the rows from table1 and populated to table2

I think ThreadPoolExecutor should do the needful here.

The best way to see how it works is to experiment with it in general. Just create a small class and see how it works. There is no shortcut there.
Hey rahul, isn't that post age old and poster more or less got his question answered? Welcome to ranch by the way.
Commons validator source distribution comes with examples. Check version of the one you are using and download the source from apache website (look for files similar to commons-validator-1.4.0-src.zip). That should get you started with validator usage.

Regarding validation in filter (assuming servlet filters), the details are not enough. Whether its a good way or not depends on what you are trying to validate. A typical use of a filter is to log message arrivals but not to validate the request content. But that doesnt mean one should not. As i said it all depends on what you are trying to achieve.
7 years ago
@Henry Wong : Nicely put...

@Mohan Mehra : as Henry rightly put, address it step by step basis. Not to be rude but a word of advice: These forums are here to help you understand things and code better. That means a fair amount of home work by original poster is expected. Bottom line - please do not expect people to code it for you.
If both threadA and threadB are going to 'modify' the context then one needs to understand what those modifications are. Modifications are to the context object itself or to the object's maintained by the context (its not clear as to what context we are talking about).

If modifications are to the context itself then you dont have any other option than locking it. Depending on 'context' code (William's question #2) you can use synchronized() or a lock.

If modifications are to the objects maintained by the context, then you can look into locking those objects instead of context.
Couple of options that i can think of:

1. Do not hand over context to threadB until threadA's changes to context are complete.

2. Hand over context to threadB if it is only going to 'use' the context and not 'modify' it. If this is the case then please have a look at java.util.concurrent.locks.ReentrantReadWriteLock
Word of caution: Since threadB can use the context while threadA is modifying it, make sure that threadB's code is not dependent on those changes. Why? because they may or may not happen by the time threadB tries to use the context.


Joseph Cho wrote:Also, if I set the boolean variables to static... shouldn't both threads be accessing the memory address of the variable? this is Why I don't get why the changes are not being reflected..


Sometimes java seems to work in strange ways but most of the times just that we are not looking at the right place. For example if you execute below code, the worker thread never ends unless you make either staticStopWork or stopWork as volatile



I am not an expert in GUI stuff but your code more or less seemed to be the case above. As Jelle pointed out volatile should make it work.