Re: RMI Serializing Error

By "calling thread" I meant an arbitrary thread that has a reference to the
HashMap.

The Collections.synchronizedMap() call can be thought of as taking all the
methods and putting synchronized(this){} blocks in them.  The exemptions for
this rule are writeObject() and readObject().  These methods are private
HashMap methods and their behaviour can not be changed by synchronizedMap().

So there are two solutions to the problem: use clone() or extend/wrap the
HashMap making sure to implement your own writeObject() and readObject()
methods.  Most, if not all the methods in the second solution must have
synchronization blocks which lock on "this" to block any external access.
The especially important methods are put() and the aforementioned
serialization methods.

I am currently using clone() to return a copy of the HashMap so that the Web
UI does not fall over at random.  After running some JMeter tests, it turns
out that the UI requests are on average 30ms longer (for HashMaps containing
400 our objects).  This small protraction in time is not human noticeable
which is acceptable.  And of course, this is not a universal benchmark and
your mileage may vary.

Thank you for your time,
Jason

On Thu, 30 Dec 2004 11:06:49 +0800, Niclas Hedhman <[email protected]> wrote:

>On Thursday 30 December 2004 02:47, Jason Sicotte wrote:
>
>> Seeming as you, (and I am certain others on the list) are more
>> knowledgeable than I on the subject of threads, let me sate my question as
>> this:  How can I modify the application outlined in
>>
>> http://archives.java.sun.com/cgi-bin/wa?A2=ind0412&L=rmi-users&F=&S=&P=3197
>>
>> to lock access to a HashMap reference from an external thread after that
>> thread has already obtained a reference?  This must be done without
>> modification to the calling thread.
>
>Sorry, the question doesn't really compute for me. "Calling Thread" is what?
>All threads of interest are calling the the HashMap. (Also, *must not* is
>pretty strong words, as there are cases when there is no way around fixing
>other people's broken systems.)
>
>I have never really understood what Collections.synchronizedMap() does, and
>never use it. If you want to complain about thread safety in the JDK, it is
>probably here the complaint should go.
>
>Never the less;
>
>Instead, I would either subclass HashMap, or (more likely) implement my own
>Map which delegates to an underlying HashMap, which are thread safe. Making
>it thread safe can be done in a few ways, where synchronized methods are the
>most obvious, but could become a bottle neck. Cloning may not be as bad as
>you think from a performance point of view. It depends a lot on the
>application type, such as how large is the HashMap and how often is it
>updated (I assume that the code you give is just exemplifying the real
>problem).
>
>This can be done without modifying the RMI client ( I assume that is what you
>mean by the "calling thread"), but the server must be modified.
>
>Cheers
>Niclas

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html