Threads in applications

[Giuseppa Cefalu]

Hi,

Could anyone explain why would one use threads in a swing application?

Thank you

[Rob Spoor]

To not block the user interface.

Let's say you create your own web browser. When a link is clicked, the contents of the linked page must be retrieved. This may take a long time, especially if the server the page is on is having problems. If you retrieve the contents from the event dispatcher thread your entire user interface will not respond until either the contents are retrieved or a timeout occurs, whichever occurs first. If you do the same from a separate thread (SwingWorker!) the event dispatcher thread is not blocked, the user interface will respond properly and you will still retrieve the contents.

So whenever a piece of code takes a bit longer (1 second is already too long, actually), use a different thread (preferable a SwingWorker).

[Giuseppa Cefalu]

Thank you,

In my case I am designing a Jtable that reads database, updates and inserts data in database tables (database is in VM and information is accessed through the internet). Would you recommend to use threads in this context?

[Rob Spoor]

Definitely. Access to databases, disks and network resources are often relatively slow, and are good candidates to do in the background.

[Giuseppa Cefalu]

Thank you!

Do you know any thing about concurrency? For example, once thr tool is in a jar file, we will install it so that all the users that can access the VM thorugh the network can have access to the databse concurrently. I am thinkimg about possible collisions between users that might insert duplicates or dirty data when several users make inserts or updates to the same table at the same time. Is concurrency an issue that the database management system is built to deal with, or should I also deal with it within the code?

[Giuseppa Cefalu]

Hi Rob,

If I do not use threads, In other words; if the application is written for a single user, is the server in charge of producing children processes so that multiple users can use the tool concurrently?

Thank you

[Rob Spoor]

I'm sorry, but I don't have an answer for you...

[Paul Clapham]

I'm not sure if I have an answer either. I think the answer is "no", but providing a correct answer would require knowing what you meant by "the server" and "children processes" and also knowing how those multiple users were connecting to, or using, those things.

[Ranganathan Kaliyur Mannar]

My understanding is that you seem to be talking about in-memory databases. If you are using a RDBMS product like Derby or HSQLDB, then, it will handle multiple users based on the ACID properties. Have to check the specific documentation on how things work.

If you are writing our own stuff, then you will have to handle multiple users. You have mentioned that multiple users access via network. Normally, in these cases, each user will be serviced by a separate thread (like a web server). Within the threads, they will try to persist to the same data source - if it is in-memory, then you will have to handle the concurrency.

[Giuseppa Cefalu]

Hi,

How can I make vectors thread safe? Could you refer me to any sources?

Thank you

[Paul Clapham]

Well, you wouldn't. "Making something thread-safe" doesn't really mean anything. What you should do instead is to write thread-safe code. The way to do that is to examine your code, decide which parts of the code are going to cause problems if two threads run those parts simultaneously, and use synchronization to prevent that from happening. Note that this doesn't involve choosing components which are alleged to be "thread-safe", it involves evaluating your specific code.

[Giuseppa Cefalu]

This is what I read about StringBuffer and Vector : "String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved. http://download.oracle.com/javase/1.5.0/docs/api/java/lang/StringBuffer.html

Also for vectors I find the following: "The Iterators returned by Vector's iterator and listIterator methods are fail-fast: if the Vector is structurally modified at any time after the Iterator is created, in any way except through the Iterator's own remove or add methods, the Iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the Iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future. The Enumerations returned by Vector's elements method are not fail-fast. "http://download.oracle.com/javase/1.4.2/docs/api/java/util/Vector.html

This is the way I see it.
Some how a String buffer methods are synchronized and they will occur in the order consistent with the order in which each thread calls those methods. When threads are implemented a Vector 's iterator fails in the face of concurrent modification. In other words; Aavector is not thread safe by a Stringbuffer is. Howeer, a vector will warn you if the method calls by the respective threads are not synchronized and this will help you during debugging.

Where can I read about threads and synchronization?

[Ranganathan Kaliyur Mannar]

Giuseppa Cefalu wrote:This is the way I see it.
Some how a String buffer methods are synchronized and they will occur in the order consistent with the order in which each thread calls those methods. When threads are implemented a Vector 's iterator fails in the face of concurrent modification. In other words; Aavector is not thread safe by a Stringbuffer is. Howeer, a vector will warn you if the method calls by the respective threads are not synchronized and this will help you during debugging.

You understanding is wrong. Let me explain:
There is no 'somehow' with StringBuffer. All key methods of StringBuffer are synchronized - importantly, both read and write methods are synchronized. For example, the toString() method is also synchronized. So, suppose you have 2 threads T1, T2. T1 is calling append and T2 is calling toString. If T1 calls append, it holds the lock and T2 has to wait till T1 is done with its call. This ensures that, when toString() on StringBuffer is called, there is no other thread 'writing' data to it - in effect, dirty reads won't happen in StringBuffer.

Now, the case is same with Vector. Both read and write methods of Vector are synchronized. For example, the add() method is synchronized. And the get(int) method is also synchronized (get internally calls elementAt in Vector which is synchronized). Even the indexOf method is synchronized. Note that these are all methods of Vector itself.

But, when you call the iterator() method, you get an instance of a class that implements the Iterator interface. This is now a different class from Vector. And the methods hasNext() and next() are not synchronized. So now, when T1 is iterating through an iterator, there is a possibility of the Vector having changed via T2. That is why you end up getting ConcurrentModificationException even when using a 'thread-safe' Vector.

You can read about method synchronization here:

[Giuseppa Cefalu]

Wonderful detailed explanation! Thank you so much! And thank you for the reference.

[Ranganathan Kaliyur Mannar]

You're welcome.