Did we had a reason to use HashMaps instead of Hashtables?, which I
belive is the correct approach. Please Comment
https://issues.apache.org/jira/browse/AXIS2-2794
Thanks
Srinath
--
Srinath Perera:
Indiana University, Bloomington
http://www.cs.indiana.edu/~hpere
+1,
then we do not need to add sync block in our code , since hashtable does
that for us.
Thanks
Deepal
> Did we had a reason to use HashMaps instead of Hashtables?, which I
> belive is the correct approach. Please Comment
>
> https://issues.apache.org/jira/browse/AXIS2-2794
>
> Thanks
> Srinath
>
IIRC the flip side of the same argument was brought as a reason.
Hashtables are slower than hashmaps due to the synching.
In how many places do we have to synch if we just use the map ? if
there are many I suggest we use the hashtable. However if there are
only one or two place where we have to s
Yes .. right now problem is it is HashMap, but there are no
synchornization as well. Please correct me if I am missing something.
Thanks
Srinath
On 6/11/07, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
IIRC the flip side of the same argument was brought as a reason.
Hashtables are slower than has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ajith Ranabahu wrote:
> IIRC the flip side of the same argument was brought as a reason.
> Hashtables are slower than hashmaps due to the synching.
> In how many places do we have to synch if we just use the map ? if
> there are many I suggest we use
On 6/12/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ajith Ranabahu wrote:
> IIRC the flip side of the same argument was brought as a reason.
> Hashtables are slower than hashmaps due to the synching.
> In how many places do we have to synch if we
We talked about this at the beginning .. and concluded that this was the
right solution because synchronizing *EVERY* access was way overkill and
would add a HUGE performance overhead.
PLEASE don't change this unless (1) we have a problem that we're trying to
solve and (2) we have some idea of
I agree if we can not see a problem we should let it be!
Thanks
Srinath
On 6/12/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
We talked about this at the beginning .. and concluded that this was the
right solution because synchronizing *EVERY* access was way overkill and
would add a HUGE pe
I've run some concurrent tests with clustering enabled where objects are
placed/read/removed from the context Maps. In this case, the services place
objects in the Map in addition to the clustering mechanism updating the
Maps. So far, I didn't face any concurrency issues. Also, synchronizing all
t
IMHO, if you have some HashMap and it is accessed concurrently, it
should be synchronized (or use ConcurrentHashMap instead). Concurrent
access on unsynchronized HashMap caused the following bug:
http://blogs.opensymphony.com/plightbo/2005/07/hashmapget_can_cause_an_infini.html.
This was a while a
Axis2 contexts use unsyncronized HashMap instead of Hashtables
--
Key: AXIS2-2794
URL: https://issues.apache.org/jira/browse/AXIS2-2794
Project: Axis 2.0 (Axis2)
Issue Type: Bug
[
https://issues.apache.org/jira/browse/AXIS2-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deepal Jayasinghe reassigned AXIS2-2794:
Assignee: Srianth Perera
> Axis2 contexts use unsyncronized HashMap instead
use unsyncronized HashMap instead of Hashtables
> --
>
> Key: AXIS2-2794
> URL: https://issues.apache.org/jira/browse/AXIS2-2794
> Project: Axis 2.0 (Axis2)
>
13 matches
Mail list logo
