DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38986>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38986 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2006-03-16 19:31 ------- This would be the last one As far as Struts Action example concerned, we are not removing actions from the table, but keep adding. So if you added the object at the time when someone is trying to read it would not problem. table.length in HashMap simply will return you the length that is one element less than actual length. In other words, the element that was just added is not going to be considered by the search. table array in a HashMap is array of Entry objects. Each element in array is object that has information about another Entry previously added to array. Entry e = table[i] get you last object and after that you do e = e.next to get previous creted entry. In other words, no matter what Entry object you started with, it has memory location reference to previously added entry. Note. The point is that is we are not using array's index here to get child entry and I do not see how you can get Circular reference that are you talking about in your response. Ok, getting back to as Struts Action paradigm. Getting Action in synchronized block degrades performance. This way you lining up all your user requests and letting them get the action one at the time waiting on each other no matter if action loaded or not. If Map is concern, It would be better decision to create all Action Objects at application start-up, so that you would use the action map as read only. Cheers ;-) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
