You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Pavel Ausianik <Pa...@epam.com> on 2002/10/28 17:55:07 UTC

RE: cvs commit: xml-soap/java/src/org/apache/soap/util/xml XMLPar serUtils.java

Hello,

I have  a question related to this commit. 

What if threads are not reused constantly, but once finished processing
something just discarded? In this case hashmap will prevent both thread and
document builder from be removed by GC.

Another question, what if Call created in one thread, but then reused in
other threads (I myself thought about having pool of Call objects) - in this
case the login of getting DocumentBuilder by current thread will likely
produce errors, which very difficult to debug.

Thanks,
Pavel

> -----Original Message-----
> From: sanjiva@apache.org [mailto:sanjiva@apache.org]
> Sent: Monday, October 28, 2002 6:37 PM
> To: xml-soap-cvs@apache.org
> Subject: cvs commit: xml-soap/java/src/org/apache/soap/util/xml
> XMLParserUtils.java
> 
> 
> sanjiva     2002/10/28 08:37:02
> 
>   Modified:    java/src/org/apache/soap/util/xml XMLParserUtils.java
>   Log:
>   added logic to share instances of DocumentBuilders on a per-thread
>   basis
>   
>   Revision  Changes    Path
>   1.6       +16 -7     
> xml-soap/java/src/org/apache/soap/util/xml/XMLParserUtils.java
>   
>   Index: XMLParserUtils.java
>   ===================================================================
>   RCS file: 
> /home/cvs/xml-soap/java/src/org/apache/soap/util/xml/XMLParser
> Utils.java,v
>   retrieving revision 1.5
>   retrieving revision 1.6
>   diff -u -r1.5 -r1.6
>   --- XMLParserUtils.java	17 May 2002 18:11:57 -0000	1.5
>   +++ XMLParserUtils.java	28 Oct 2002 16:37:02 -0000	1.6
>   @@ -57,7 +57,7 @@
>    
>    package org.apache.soap.util.xml;
>    
>   -// JAXP packages
>   +import java.util.HashMap;
>    import javax.xml.parsers.*;
>    import org.xml.sax.*;
>    import org.xml.sax.helpers.*;
>   @@ -73,6 +73,7 @@
>     */
>    public class XMLParserUtils {
>      private static DocumentBuilderFactory dbf = null;
>   +  private static HashMap docBuilderTable = new HashMap ();
>    
>      static {
>        // Create a default instance.
>   @@ -132,12 +133,20 @@
>       */
>      synchronized public static DocumentBuilder getXMLDocBuilder()
>        throws IllegalArgumentException {
>   -    // Step 2: create a DocumentBuilder that satisfies the 
> constraints
>   -    // specified by the DocumentBuilderFactory
>   -    try {
>   -      return dbf.newDocumentBuilder();
>   -    } catch (ParserConfigurationException pce) {
>   -      throw new IllegalArgumentException(pce.toString());
>   +    // if a document builder has already been created for 
> this thread 
>   +    // then just reuse that. otherwise create a new one 
> and remember it.
>   +    Thread t = Thread.currentThread ();
>   +    DocumentBuilder db = (DocumentBuilder) docBuilderTable.get (t);
>   +    if (db != null) {
>   +      return db;
>   +    } else {
>   +      try {
>   +        db = dbf.newDocumentBuilder();
>   +        docBuilderTable.put (t, db);
>   +        return db;
>   +      } catch (ParserConfigurationException pce) {
>   +        throw new IllegalArgumentException(pce.toString());
>   +      }
>        }
>      }
>    }
>   
>   
>   
> 
> --
> To unsubscribe, e-mail:   <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
> 

--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>


Re: cvs commit: xml-soap/java/src/org/apache/soap/util/xml XMLParserUtils.java

Posted by WJCarpenter <bi...@carpenter.org>.
> Yes, that would be the case with this approach. The better way
> would be to use thread local storage .. I just talked to Bill Nagy and
> he said he would look into committing a patch to change this part.
> (He's familiar with thread local storage and I'm not.)

I believe using ThreadLocal will make the code technically ineligible
for use by EJBs, but I don't know if there are any EJB containers which
enforce that.




--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>


Re: cvs commit: xml-soap/java/src/org/apache/soap/util/xml XMLParserUtils.java

Posted by WJCarpenter <bi...@carpenter.org>.
> Yes, that would be the case with this approach. The better way
> would be to use thread local storage .. I just talked to Bill Nagy and
> he said he would look into committing a patch to change this part.
> (He's familiar with thread local storage and I'm not.)

I believe using ThreadLocal will make the code technically ineligible
for use by EJBs, but I don't know if there are any EJB containers which
enforce that.




Re: cvs commit: xml-soap/java/src/org/apache/soap/util/xml XMLParserUtils.java

Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi Pavel,

> What if threads are not reused constantly, but once finished processing
> something just discarded? In this case hashmap will prevent both thread
and
> document builder from be removed by GC.

Yes, that would be the case with this approach. The better way
would be to use thread local storage .. I just talked to Bill Nagy and
he said he would look into committing a patch to change this part.
(He's familiar with thread local storage and I'm not.)

> Another question, what if Call created in one thread, but then reused in
> other threads (I myself thought about having pool of Call objects) - in
this
> case the login of getting DocumentBuilder by current thread will likely
> produce errors, which very difficult to debug.

No that should work fine. There will not be any relevant state inside
the doc builder - so I believe the 2nd thread will just pick up a
different doc builder and life will go aon jus fine.

Bye,

Sanjiva.



--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>


Re: cvs commit: xml-soap/java/src/org/apache/soap/util/xml XMLParserUtils.java

Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi Pavel,

> What if threads are not reused constantly, but once finished processing
> something just discarded? In this case hashmap will prevent both thread
and
> document builder from be removed by GC.

Yes, that would be the case with this approach. The better way
would be to use thread local storage .. I just talked to Bill Nagy and
he said he would look into committing a patch to change this part.
(He's familiar with thread local storage and I'm not.)

> Another question, what if Call created in one thread, but then reused in
> other threads (I myself thought about having pool of Call objects) - in
this
> case the login of getting DocumentBuilder by current thread will likely
> produce errors, which very difficult to debug.

No that should work fine. There will not be any relevant state inside
the doc builder - so I believe the 2nd thread will just pick up a
different doc builder and life will go aon jus fine.

Bye,

Sanjiva.