Is the java 1.5 default SAXParser thread safe.

I used the following code to create a parser and validate my xml data.
But the following code is causing too many open file issue.
After doing some analysis I understood that each object of parser is open the file "file://var/app/bea/files/wfinf/xmlschema/WorkflowDecisionResponse.xsd".
So if I comment the setProperty method it will work fine.
My question is this parser is thread safe so that I can create single instance of parser and can be shared by all my thread?
If not can some body suggest a better idea to validate it.
public static boolean validate(String XMLData){
     SAXParserFactory factory = SAXParserFactory.newInstance();
     factory.setNamespaceAware(true);
     factory.setValidating(true);
     SAXParser parser = factory.newSAXParser();
     parser.setProperty("http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema");
     parser.setProperty("http://java.sun.com/xml/jaxp/properties/schemaSource", "file://var/app/bea/files/wfinf/xmlschema/WorkflowDecisionResponse.xsd");
       try{
          parser.parse(new InputSource(new StringReader(XMLData)), new DummyHandlerImpl());
       }catch(Exception e) {
           return false;
       return true;
}

Hi There,
I found this thread of yours with no reply from anybody.
I'm also facing a similar issue. Did you found a solution to this.
If yes please share.
Regards,
Mayank

Similar Messages

Are the service(), doPost() and doGet() methods THREAD-SAFE?

Please Let Me know If service(), doPost() and doGet() are Thread-safe. If they are not thread safe, How to make them thread-safe?

Please Let Me know If service(), doPost() and doGet() are Thread-safe. They are not.
If they are not thread safe, How to make them thread-safe?The best way is to avoid writing code that depends on a servlet's thread safety; i.e., no servlet instance variables - keep everything local to the method. Else, you'll want to learn about synchronization.
[JavaWorld article - Write thread-safe servlets|http://www.javaworld.com/javaworld/jw-07-2004/jw-0712-threadsafe.html].
~

How can we generate the java doc for default package

hello....
i using Netbeans 6.5 with JDK 1.5 and JRE 1.6. I generated comment and selected generate javadoc option from Netbeans.
It genearted javadoc for all packages except the default package.Please help me to generate javadoc for default package.

You need to pass in source filenames (rather than package names) with the javadoc command on the command line. (I don't know if this can be done in NetBeans)
"I have refined this fix to handle classes in unnamed packages. A link with the label <unnamed package> now appears at the top of the packge list when classes in unnamed packages are specified on the command line."
stddoclet: Include package info when passing in source filenames (*.java)
10-Fix Delivered,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4359386
Also see:
stddoclet: Want default (i.e. unnamed) package to appear in package list
11-Closed, duplicate of 4359386
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4213968

Why are the weblogic.kernel.Default Execute Threads used by WLS Kernel

In my Admin Console, it's displaying 10 out of the 15 weblogic.kernel.Default Execute Threads are used by the WLS Kernel user. The total requests column for these threads are showing 0. The other 5 threads are showing 20K to 40K requests. Why is the WLS Kernel users hogging these threads and not allowing the applications to use them?

Hi,
As work enters a WebLogic Server, it is placed in an execute queue. This work is then assigned to a thread within the queue that performs the work.
By default, a new server instance is configured with a default execute queue, weblogic.kernel.default, that contains 15 threads.
Go through the following link and find the usefull information on this issue.
http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_executequeuetable.html
Regards
Anilkumar kari

RFC JAVA CONNECTOR CAUSING THE JAVA TO BE IN SAFE MODE

Hi GURUS :
We have SolMan with JAVA as Add in . Now during the JSPM Launch the JSPM Aborts with the Err Messages as shown :
in trace file dev_jrfc.trc and in defaultTrace we have this same message :
>>>>
#1.5 #0003BA951BE1004C0000000500007486000456B88DE8595D#1221250561628#com.sap.engine.services.rfcengine##com.sap.engine.services.rfcengine#J2EE_GUEST#0##n/a##d7e28da080f311ddc3de0003ba951be1#SAPEngine_Application_Thread[impl:3]_27##0#0#Error#1#/System/Server#Plain###Bean SLDJAVA_ACCESSOR_REQUESTnot found on host <fqdn of host name> ProgId =JCOLDAPI: Path to object does not exist at rfcaccessejb_stateful, the whole lookup name is rfcaccessejb_stateful/SLDJAVA_ACCESSOR_REQUEST.registered entries for FuctionName=JNDIName : {}#
#1.5 #0003BA951BE1004C0000000600007486000456B88DE85D04#1221250561629#com.sap.engine.services.rfcengine##com.sap.engine.services.rfcengine.handleRequest#J2EE_GUEST#0##n/a##d7e28da080f311ddc3de0003ba951be1#SAPEngine_Application_Thread[impl:3]_27##0#0#Error##Plain###java.lang.RuntimeException: Bean SLDJAVA_ACCESSOR_REQUESTnot found on host <fqdn of host name>, ProgId =JCOLDAPI: Path to object does not exist at rfcaccessejb_stateful, the whole lookup name is rfcaccessejb_stateful/SLDJAVA_ACCESSOR_REQUEST.#
#1.5 #0003BA951BE1004C0000000700007486000456B88DE85E8C#1221250561629#com.sap.engine.services.rfcengine##com.sap.engine.services.rfcengine.handleRequest#J2EE_GUEST#0##n/a##d7e28da080f311ddc3de0003ba951be1#SAPEngine_Application_Thread[impl:3]_27##0#0#Error##Plain###java.lang.RuntimeException: Bean SLDJAVA_ACCESSOR_REQUESTnot found on host <fqdn of host name>, ProgId =JCOLDAPI: Path to object does not exist at rfcaccessejb_stateful, the whole lookup name is rfcaccessejb_stateful/SLDJAVA_ACCESSOR_REQUEST.
     at com.sap.engine.services.rfcengine.RFCDefaultRequestHandler.handleRequest(RFCDefaultRequestHandler.java:138)
     at com.sap.engine.services.rfcengine.RFCJCOServer$J2EEApplicationRunnable.run(RFCJCOServer.java:254)
     at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
     at java.security.AccessController.doPrivileged(Native Method)
     at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:102)
     at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:172)
<<<
Now , this JCOLDAPI is Java RFC Connector with User PORTALADMIN and at the ABAP Side we see that the J2EE_ADMIN pwd was changed by this PORTALADMIN !! We had at the same time stamp, the message in the log file of the JSPM that credential supplied to log in to J2EE Engine is not valid ( 'cause, the PORTALADMIN had changed the PW
of the J2EE_ADMIN ) - While attempting to Launch the JSPM for JAVA Patches > It aborts with the same above message !!
Half of the SW Comp were updated and rest half aborts repeatedly with the above message.
Same way the Vis Admin won't start with the msg that Credential to connect J2EE is not valid. Although there was no change at the Config Tool Secure Store > J2EE Admin and SAPSR3DB passwords !!
I have changed both the J2EE_ADMIN and the PORTAL ADMIN to the User Type Service User ( note 622464 ) ..have
kept the same pw at ABAP and configtool secure store. But the java is not coming up neither through SMICM nor through the startsap j2ee command as SMPADM.
i.e. it would comeup only in SAFE Mode !!
This JCOLDAPI RFC Java Connector 's PORTALADMIN has several rights at the ABAP Side and is used for EWA Purpose.
JAVA is running in SAFE mode and no matter how many time I try at the config tool Side to bring it in normal mode it is not swithcing to normal mode > I disble the safe mode at the ConfigTool Side > Apply > Save . > Restart the JAVA through the jcmon > shutdown and restart cluster under #10 Cluster Admin Menu > it is coming up only in SAFE mode again with the abvoe error message !!! Restart through the SMICM don't even work at all !!. Also, the system is slow ..even to come in safe
mode JAVA takes about 45 minutes !!!
Also, since the JAVA is coming up only in safe mode the SLD and the browser page is not available. The jcomon displays the instance status as ' Synchronizing Binaries' since
last 20 hours ..this means that the instance is in hang state.
Any idea how to solve this problem ?
Thanks a Lot in Advance,
Regards,
- Ishan
Edited by: ISHAN P on Sep 13, 2008 2:54 PM

hi ishan,
do you have solved the problem?? as ??
thanks
umberto

Java.lang.reflect.Constructor thread safe ?

When you have a Constructor object in Java.
Is calling the newInstance method on the same Constructor object from multiple threads safe.
Or is this not thread safe leading to wrongly constructed objects?

ejp wrote:
And as Constructors are immutable, it's hard to see how it's going to get altered.Constructors are basically immutable, but they have at least one state which can make the difference between newInstance working or failing.
As you can see in the following example, setAccessible() is not something you would want to set to different values in different threads.
import java.lang.reflect.Constructor;
public class Main {
    public static void main(String... args) throws Exception {
        Constructor cons = Private.class.getDeclaredConstructor();
        cons.setAccessible(false);
        try {
            System.out.println("cons.isAccessible()= " + cons.isAccessible());
            cons.newInstance();
            throw new AssertionError("IllegalAccessException expected");
        } catch (IllegalAccessException expected) {
            // ignored
        cons.setAccessible(true);
        System.out.println("cons.isAccessible()= " + cons.isAccessible());
        cons.newInstance();
class Private {
    private Private() {
}

Is the Sun JNDI LDAP provider thread safe?

Hi,
The JNDI documentation states that the Context implementation is not required to be thread safe although some providers provide thread safety. My question is whether the Sun JNDI LDAP provider is thread safe or do we have to synchronize on the Context instance?
Thanks

Read this: http://java.sun.com/j2se/1.3/docs/api/javax/naming/Context.html
The answer, I think is no you need to synchronize accesses yourself. If you're using it from a servlet container, this should be OK, since each request is on a separate thread.

Is the ThreadpoolExecutor thread safe?

Is the ThreadpoolExecutor thread safe? Is it safe to use a ThreadpoolExecutor from a multiple thread contexts?

If the API documentation says it's thread-safe, then it is. Otherwise you must assume it is not.

Native library NOT thread safe - how to use it via JNI?

Hello,
has anybody ever tried to use a native library from JNI, when the library is not thread safe?
The library (Windows DLL) was up to now used in an MFC App and thus was only used by one user - that meant one thread - at a time.
Now we would like to use the library like a "server": many Java clients connect the same time to the library via JNI. That would mean each client makes its calls to the library in its own thread. Because the library is not thread safe, this would cause problems.
Now we discussed to load the library several times - separately for each client (for each thread).
Is this possible at all? How can we do that?
And do you think we can solve the problem in this way?
Are there other ways to use the library, though it is not thread safe?
Any ideas welcome.
Thanks for any contributions to the discussion, Ina

(1)
has anybody ever tried to use a native library from
JNI, when the library (Windows DLL) is not thread safe?
Now we want many Java clients.
That would mean each client makes its calls
to the library in its own thread. Because the library
is not thread safe, this would cause problems.Right. And therefore you have to encapsulate the DLL behind a properly synchronized interface class.
Now the details of how you have to do that depends: (a) does the DLL contain state information other than TLS? (b) do you know which methods are not thread-safe?
Depending on (a), (b) two extremes are both possible:
One extreme would be to get an instance of the interface to the DLL from a factory method you'll have to write, where the factory method will block until it can give you "the DLL". Every client thread would obtain "the DLL", then use it, then release it. That would make the whole thing a "client-driven" "dedicated" server. If a client forgets to release the DLL, everybody else is going to be locked out. :-(
The other extreme would be just to mirror the DLL methods, and mark the relevant ones as synchronized. That should be doable if (a) is false, and (b) is true.
(2)
Now we discussed to load the library several times -
separately for each client (for each thread).
Is this possible at all? How can we do that?
And do you think we can solve the problem in this
way?The DLL is going to be mapped into the process address space on first usage. More Java threads just means adding more references to the same DLL instance.
That would not result in thread-safe behavior.

Repaint() is not thread-safe?

I saw a description that says repaint() is thread-safe in an old swing tutorial, but not in the current tutorial and its javadoc. So can I assume repaint() is not thread-safe and I should call it from EDT? ... Or if they are thread-safe, why does Sun not document it?

repaint() calls paint() on EDT... but it calculates dirty region on the current thread and does not get AWTTreeLock.I don't think so.
repaint() is a java.awt.Component method and doesn't know about Swing's RepaintManager and dirty regions. There may be somthing similar at the AWT level that escaped me, but looking at the JDK1.6 source code, java.awt.Component.repaint() just repaints the whole component.
Now repaint(long, int, int, int, int) has two versions.
At the AWT level, it just posts a paint event for the specified region. No race condition, and no risk that he region be wrong, but possibility to invoke multiple paint(Graphics) that overlap, that is, to paint several times the same area - it may be an optimization problem, but it doesn't jeopardize the consistency of the drawing.
At the Swing level, it does compute dirty regions. In Repaint manageer, the call to extendDirtyRegion(...) is protected within a synchronized block, but the code before that is not. From a quick look, that code is:
1) walking up the component hierarchy to find the root, which may not be thread-safe, but a well-behaved application shouldn't change the hierarchy from outside the EDT.
2) walking up a chain of "delegate" RepaintManager, which I knew nothing about... Apparently it's a sun's implementation specific construct, each JComponent can be assigne d a delegate RepaintManager. Again I would claim that such things should not happen outside of the EDT, but I haven't found documentation about this.
Edited by: jduprez on Jul 20, 2009 2:37 PM
so no, technically, I can't prove repaint(long, int,int,int,int) is thread-safe.
But a well-behaved application that updates its widgets on the EDT shouldn't worry (that is, repaint(...) calls can still be invoked outside of the EDT).
Edited by: jduprez on Jul 21, 2009 7:04 PM - typos

Need thread safe way to access read-only objects

I have been working on a lot of projects and all the developers agree that they want thread safe code when called by many threads. It's rare developers are making statement like: "Data are not corrupted often so don't bother" or "It's not thread safe, but that will not often create issues".
In TopLink client session itself is thread safe but not the persistent object themselves. Via client session, if you want thread safe access you need to put a lock on CacheKey and it's not a public/supported API. So the only thread safe access is via unit of work.
We would like fast access to objects. We have a batch process that just need read-only access to objects. We need to read via unit of work to get thread safe access. But we just need the clone when we read via unit of work, we don't need the backup for change detection.
However, TopLink doesn't have a mean to do that.
Please push implementation of Bug5998333[WANT THREAD SAFE AND CORRECT ISOLATION WITH OBJECTS FROM ADDREADONLYCLASS]
In Hibernate, by design, all access are always thread safe. Accessing read-only object just create one copy (a clone), no backup needed.
Oracle claims that TopLink is fast. I wonder if their performance testing code is thread safe, so access objects via unit of work or they take the shortcut of accessing objects from client session. Also, reliable performance comparison should use conform in unit of work.

As you stated the UnitOfWork offers you your desired functionality, you would just like an improvement in performance.
In TopLink 10.1.3 (or 11g preview) you have a few options:
- Use a UnitOfWork an live with the slight overhead of the back copies (it will only add 5-30 % overhead to your processing)
- Instead use an isolated client session, this will not require any cloning or backup clones, but also does not allow any caching.
- Use change tracking, TopLink added attribute-level change tracking in 10.1.3, when used the UnitOfWork does not create backup clones. In 10.1.3 it was mainly used for CMP and requires code generation, but you could implement or weave the code yourself. In TopLink 11g, change tracking is weaved by default with JPA and the weaver can also be used with POJO objects.
I agree that having a feature to mark an object as transactionally read-only would be desirable, it seems like you have logged the enhancement. You could try escalting the enhancement through Oracle support, but since it is an enhancement and not a bug, it is probably beyond what support offers. You may wish to investigate services, or potentially join the open source Eclipse EclipseLink project which the next version of TopLink is being developed under and take part in the feature yourself.

Thread-safe alternative to XmlValue

Hi,
I'm using bdb xml in an application which visualizes 3d data stored in xml. When I load the data, it will be written into the db and I#m using XPath as query language. This works quite good, but as I'm using multiple threads within my application, I can't use XmlValues for referencing into the database, because they are not thread-safe. But I need to store at least some of those references to get quick access to some data, or to run a new query, based on a result node from an earlier query, later from another thread. Those referenced nodes will change during runtime, so indices won't help. So what can I do or did I miss something?
Thanks
Bjoern

Bjoern,
You may have to explain a bit more, especially the part about "referenced nodes will change during runtime." XmlValue objects that reference nodes are only guaranteed valid until the either (1) the XmlResults object containing them has been deleted or (2) the transaction in which they were retrieved ends. There are exceptions but those are the general rules.
The interfaces, XmlValue::getNodeHandle() and XmlContainer::getNode() exist to allow an application to store a string value that can be later resolved quickly back into an XmlValue. This works well unless the referenced node has been removed. It may be the answer you are looking for.
Regards,
George

What does it mean to be "thread safe"?

What does it mean to be "thread safe"?
I am working with a team on a project here at work. Someone here suggested that we build all of our screens during the initialization of the application to save time later. During the use of the application, the screens would then be made visible or invisible.
One of the objections to that idea was that the swing components (many of which we use) are not thread safe. Can anyone tell me what the relevance of that is?
Thanks

To understand why Swing is not thread safe you have to understand a little bit of history, and a little bit of how swing actually works. The history(short version) is that it is nearly impossible to make a GUI toolkit thread safe. X is thread safe(well, sorta) and it's a really big mess. So to keep things simple(and fast) Swing was developed with an event model. The swing components themselves are not thread safe, but if you always change them with an event on the event queue, you will never have a problem. Basically, there is a Thread always running with any GUI program. It's called the awt event handler. When ever an event happens, it goes on an event queue and the event handler picks them off one by one and tells the correct components about it. If you have code that you want to manipulate swing components, and you are not ON the awt thread(inside a listener trail) you must use this code.
SwingUtilities.invokeLater( new Runnable() {
public void run() {
// code to manipulate swing component here
});This method puts the defined runnable object on the event queue for the awt thread to deal with. This way changes to the components happen in order, in a thread safe way.

JDK 1.4.2 Collections.unmodifiableMap() thread safe?

Hello,
doesn anyone know if the call to Collections.unmodifiableMap() is thread safe.
Thanks
Marc

What do you mean?
The Collections.unmodifiableMap() doesn't modify anything so in one sense it is thread safe, however it doesn't guarentee you won't modify the underlying map in anothe thread so it won't stop you from doing unthread safe behaviour.

Is weblogic jax-ws generated client thread safe

Hi
I want to use JAX-WS webservice on weblogic 10.3.
Is there any best practices on how to generate the client stub ? Are the client stubs generated by weblogic thread-safe or is there any pool to implement.
I've read on some old forum posts that with older versions of weblogic client stub was not thread safe when using SSL : is it always the case ?
Regards
Sébastien

Hello Ravish,
Can you please confirm the following:
1) Check the Admin>Web Services Utilization page in CRMOD to see if the request is received
2) Do you receive any response from CRMOD on the client side and if so, please post the SOAP response
3) Have you tried other objects and had any issues with them?
Thanks,
Sean

Is the java 1.5 default SAXParser thread safe.

Similar Messages

Maybe you are looking for