Thread Safety Issue with DOM

I am parsing an XML into a DOM object using the Xerces parser that is packaged with JDK 1.5.
First, I create a new instance of the DocumentBuilderFactory and then using the factory, create a new DocumentBuilder. I then parse the XML using the DocumentBuilder to obtain a DOM object.
Somehow, I am seeing the same DOM object being used for different XMLs.
Is there a thread safety issue with the Xerces parser?

certainly, Xerces parser is not thread safe. You have to provide thread safety by making sure that only one thread is allowed to access DocumentBuilder object.

Similar Messages

Thread Safe Issue with Servlet

I saw the following statement in one of the J2EE compliant server documentations:
"By default, servlets are not thread-safe. The methods in a single servlet instance are usually executed numerous times simultaneously (up to the available memory limit)."
I'm quite concerned with this statement for the primary reason that (I'm trying to reason by reading it out loud) servlets are not going to be thread-safe especially when available memory hit really really low!! So, when the application is still having sufficient memory, we will not likely run into concurrency problems, i.e the happy scenario for a short period after server is started. BUT, good things don't last long.. Anyway, hope someone can explain to me with more insights. Thanks.

Don't worry, memory occupation and thread safety are not related at all.
In my opinion, the following is the meaning of the statement you quote.
Since the servlet specification doesn't force any implementation to spawn a new servlet object upon each request (and this should be a real memory hit!), nor to synchronize calls to servlet methods, you should always code your servlet in a "stateless" fashion: you should be aware the same method on the same object could (and probably will) be called concurrently if multiple concurrent client requests are submitted.
Hope I've been clear enough...

THREAD SAFETY ISSUE OF SERVLET

It is possible that one instance of a sevlet is accessed by multiple
client , then how is the concurrency issue taken care of? Especually thread safety?

It's not, you have to handle it yourself.
That's why it's a good idea to never put instance variables in servlets. The basic technique is to store anything you need to save between requests in the current user's session (which you get by calling request.getSession()). During a call to service() (or, more frequently, to doGet or doPost, you're safe if you use whatever is present in the request and response argument, including servlet config parameters, request parameters, request attributes, and session attributes.
If you want to write some "real" servlet app, you should have a look at one of the frameworks, like Jakarta Struts or OpenSymphony WebWorks.

Thread Dump issue with LD_ASSUME_KERNEL=2.4.1

Hi ,
When I take Thread Dump using 'jstack <PID>' in JDK 1.5 it givss me "sun.jvm.hotspot.debugger.DebuggerException" in the dump nothing more
I set LD_ASSUME_KERNEL=2.4.1 in my server to avaoid some other issue ( JVM crash some times)
Surprisingly, I can not stop my server ( my java process ) after that using our Shutdow scripts , Ctrl C or even "kill -9 <PID>",
I have to restart the machine or manually release uncleaned resources that my server occupied and restart the server
This happens Redhar 9 as well as in Linux ES.
Anybody faced similar problem?
Any help or information regarding this is highly apprecialted
Vasu
Thread Dump Output:
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Meth
od)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(Li
nuxDebuggerLocal.java:431)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(Linux
DebuggerLocal.java:109)
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_re
gs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(L
inuxDebuggerLocal.java:134)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebugge
rLocal.java:437)
at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48)
at sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86
JavaThreadPDAccess.java:75)
at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:252)
at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:211)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:42)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:41)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:204)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:58)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Meth
od)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(Li
nuxDebuggerLocal.java:431)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(Linux
DebuggerLocal.java:109)
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_re
gs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(L
inuxDebuggerLocal.java:134)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebugge
rLocal.java:437)

@brain0
I've downloaded the glic-2.3.6 sources from gnu, so I could build it from those. I'm however reluctant to do this because I really don't want to break my install.
I do agree with you on the NPTL statement, but pvs relies on allegro, which relies on LinuxThreads. Allegro is not being ported to new versions of glibc, so that approach is unfortunately not viable.
@iphitus
I wasn't very specific - it's allegro as in a lisp environment.
I think I'll try and install an old version of arch on wmware instead. Is there anywhere you can check out glibc version numbering on old arch install isos (ie. do I need arch-0.[1-9].iso)? And anywhere you can download the old isos (tried filewatcher, but a lot of the older sites seem broken)?
Thanks for the replies,
Mads
PS. I noticed that you recommended slackware for old kernels in another thread. I'm however in a bit different situation as I need old versions of glibc. Furthermore I would prefer sticking to arch, but was wondering whether there were any specific reasons for not doing that.

Does SimpleDateFormat still have Thread Safety Issue in jdk 1.4.2_8?

Hi,
We are using jdk1.4.2_08 and experience following error message intermittently, sometimes once in 5000 or 10000 or 2/3 times in 20000 message processing.
On one occassion, it reported as Empty String and other time it reported as ".20042005E200420054E". I won't suspect the input that's coming to this class since it works with same message over and over.
2005-07-18 19:13:54,733 [RMI TCP Connection(6960)-10.120.102.97] INFO org.jboss.logging.util.LoggerStream write(140): java.lang.NumberFormatException: empty String
2005-07-18 19:13:54,740 [RMI TCP Connection(6960)-10.120.102.97] INFO org.jboss.logging.util.LoggerStream write(140): at java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:983)
2005-07-18 19:13:54,745 [RMI TCP Connection(6960)-10.120.102.97] INFO org.jboss.logging.util.LoggerStream write(140): at java.lang.Double.parseDouble(Double.java:220)
2005-07-18 19:13:54,751 [RMI TCP Connection(6960)-10.120.102.97] INFO org.jboss.logging.util.LoggerStream write(140): at java.text.DigitList.getDouble(DigitList.java:127)
2005-07-18 19:13:54,756 [RMI TCP Connection(6960)-10.120.102.97] INFO org.jboss.logging.util.LoggerStream write(140): at java.text.DecimalFormat.parse(DecimalFormat.java:1070)
2005-07-18 19:13:54,761 [RMI TCP Connection(6960)-10.120.102.97] INFO org.jboss.logging.util.LoggerStream write(140): at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1705)
2005-07-18 19:13:54,767 [RMI TCP Connection(6960)-10.120.102.97] INFO org.jboss.logging.util.LoggerStream write(140): at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1156)
2005-07-18 19:13:54,772 [RMI TCP Connection(6960)-10.120.102.97] INFO org.jboss.logging.util.LoggerStream write(140): at java.text.DateFormat.parse(DateFormat.java:333)
It seems like some people have reported BugID 4228335 and there are few associated bugs. I assumed these are fixed in jdk1.4.
Can anyone please suggest if this kind of issues still exist in jdk1.4.2?
Here is the piece of code.
private static SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public Object convert(Class type, Object inValue) {
if(inValue == null)
return null;
NFDate ret = (NFDate) ClassDirectoryFactory.GetInstance().getClassInstance(NFDate.CLASS_KEY);
if (inValue instanceof Date) {
ret.setDate((Date)inValue);
} else if (inValue instanceof String) {
String str = inValue.toString();
if (str != null && str.length() > 0) {
DateFormat format = DateFormat.getDateTimeInstance();
format.setLenient(true);
try {
ret.setDate(format.parse(str));
} catch (ParseException e) {
try {
ret.setDate(DATE_FORMAT.parse(str));
} catch (ParseException e1) {
throw new DateConversionException("Unable to convert the String to NFDate. " +
"Exception: " + e + " - expected format is (" + format.format(new Date()) + ")", e1);
else {
if (!ret.getIsNullDate()) ret.reset();
} else {
String msg = "Conversion from " + inValue.getClass().getName() + " to " + NFDate.class.getName() +
" is not supported";
throw new DateConversionException(msg);
return ret;
Thanks much in advance.
Saikat

It doesn't look like the format classes will ever be made thread safe. The fact that they aren't isn't a bug, it is a design choice that Sun made. If you need them to be thread safe, then you will have to do the synchronization yourself.
If you have a finite number of threads for you application (like a thread pool) then you might consider using ThreadLocal so that separate threads will not be trying to access the same formatter.

Ios 4 threaded email issue with outlook inbox?

Anyone else have mail in their outlook inbox get removed or otherwise hidden when threading is turned on in IOS 4?
I can see the full threaded conversation on the phone, but only the most recent message in a thread is in my outlook inbox.
Input, solutions?

Hi. This is a very delayed post to your original. I would like though to ask if you still have fully threaded emails in your iPhone. Since iOS 4.1 there are apparent issues, and it depends how you define 'threaded'. I am using Gmail and they have a threaded/conversations method of reading mail, very useful to see the entirety of a discussion. On my new iPhone 4 using the iPhone native mail app will not show threaded, only all of the messages from the other party, I'd need to scroll through a message to see my own input.. Or look in the Sent Mail folder. Both of which seem antiquated to me. I was interested in your post as you describe seeing your threaded mail properly on iPhone. Is this still the case?
Thanks
AMH.

Workaround for LineBreakMeasurer thread safety issues?

Basically, we have a servlet that returns a png in response to a GET request containing a String, and info on the font, size, size of area the text needs to fit in, and color to render it in. Periodically the webserver locks up as requests get stuck in the servlet!
After digging around, I found out that Graphics 2D ops are safe, as long as each thread has it's own instance. No problem there!
The problem is, we want to break the string, and make it fit inside the area given. And it turns out, LineBreakMeasurer eventually calls the method getEngine() on SunLayoutEngine, and threads lock up in there.
Here's the code from SUN:
SunLayoutEngine extract listed below
public final class SunLayoutEngine implements LayoutEngine, LayoutEngineFactory {
    private static native void initGVIDs();
    static {
     initGVIDs();
    private LayoutEngineKey key;
    private static LayoutEngineFactory instance;
    public static LayoutEngineFactory instance() {
        if (instance == null) {
            instance = new SunLayoutEngine();
        return instance;
    private SunLayoutEngine() {
        // actually a factory, key is null so layout cannot be called on it
    public LayoutEngine getEngine(Font2D font, int script, int lang) {
        return getEngine(new LayoutEngineKey(font, script, lang));
// !!! don't need this unless we have more than one sun layout engine...
    public LayoutEngine getEngine(LayoutEngineKey key) {
        HashMap cache = (HashMap)cacheref.get();
        if (cache == null) {
            cache = new HashMap();
            cacheref = new SoftReference(cache);
        *HERE IS WHERE WE LOCKUP VVV*
        LayoutEngine e = (LayoutEngine)cache.get(key);
        if (e == null) {
            e = new SunLayoutEngine(key.copy());
            cache.put(key, e);
        return e;
    private SoftReference cacheref = new SoftReference(null);
    private SunLayoutEngine(LayoutEngineKey key) {
        this.key = key;
    public void layout(FontStrikeDesc desc, float[] mat, int gmask,
                       int baseIndex, TextRecord tr, boolean rtl, Point2D.Float pt, GVData data) {
        Font2D font = key.font();
        FontStrike strike = font.getStrike(desc);
        nativeLayout(font, strike, mat, gmask, baseIndex, tr.text, tr.start, tr.limit, tr.min, tr.max, key.script(), key.lang(), rtl, pt, data);
    private static native void nativeLayout(Font2D font, FontStrike strike, float[] mat, int gmask, int baseIndex,
                                            char[] chars, int offset, int limit, int min, int max,
                                            int script, int lang, boolean rtl, Point2D.Float pt, GVData data);
}Even though each thread is using it's own LBM instance, they will often lock up inside SunLayoutEngine.
Note the factory method always returns the same instance, which will be shared by all threads!
I've filed a bug against sun. I am open to any workarounds you may have.
And for those of you using various java based report generators, and getting lockups, I think this may be related. :)
Edited by: djoyce on Oct 16, 2007 2:12 PM
Edited by: djoyce on Oct 16, 2007 2:15 PM

Okay, this class is it's own factory, and only one instance is ever created. GlyphLayout calls instance(), and getEngine on that, and then all the threads pile up in the weakref'd hashmap.
at java.util.HashMap.get(HashMap.java:348)
at sun.font.SunLayoutEngine.getEngine(SunLayoutEngine.java:113)
at sun.font.GlyphLayout$EngineRecord.init(GlyphLayout.java:565)
at sun.font.GlyphLayout.nextEngineRecord(GlyphLayout.java:439)
at sun.font.GlyphLayout.layout(GlyphLayout.java:371)
at sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:267)
at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:252)
at sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:522)
at sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:451)
at sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:397)
at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:313)
at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:548)
at java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:340)
at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:422)
at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:395)

SimpleDateFormat thread safety issue

I have a servlet that instantiates an object of a class for every request in post method, which makes that variable local to that method. This class has "private final DateFormat DOB_FORMAT = new SimpleDateFormat("MM/dd/yyyy");" and a method that calls DOB_FORMAT.parse().
Even though the instance that has DOB_FORMAT is local we frequently see NumberFormatException on valid dates. So I am wondering if there is a bug/functionality that I am not aware of such that DOB_FORMAT is being shared accross requests. Could somebody advise?

DrClap wrote:
From the API documentation for SimpleDateFormat:
"Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally."Okay, I stand corrected, however, I still think that as long as you are not changing timezones, patterns, etc, that it is safe. I could easily be wrong, though.
Edit: @OP It might help to see the code in question.

Question on thread safety with Sevlet action method

I have an application that runs well but seems to have trouble with multiple users and I suspect that there is some thread safety issue involved.
It is a Struts application and I have all of my execute methods of the Acton classes are all synchronized which I thought would take care of any cross user issues but it does not seem to have done that.
The Action classes do have some instance variables which may be the problem as well as possibly a few utility string classes with static methods that are not synchornized. I keep some db connection cached in the session object but this should not be shared between users.
My question is, with the execute method synchronized how or where could I be getting crosstalk between users (each with their own sessions)?
I was thinking of packaging my Action class as seperate object with the actual Action class just allocate what I need (messages and locale) and pass them through a freshly instantiated "old action class". That should solve any instance variable cross talk.
I am assuming that any local variables in the execute method would not have any exposure as they should be thread specific and allocated on the runtime stack for that thread call.
Am I missing anything important?
Thanks in advance
---John Putnam

     * Creates a new instance of a {@link javax.xml.parsers.DocumentBuilder}
     * using the currently configured parameters.
    public DocumentBuilder newDocumentBuilder()
        throws ParserConfigurationException
        /** Check that if a Schema has been specified that neither of the schema properties have been set. */
        if (grammar != null && attributes != null) {
            if (attributes.containsKey(JAXPConstants.JAXP_SCHEMA_LANGUAGE)) {
                throw new ParserConfigurationException(
                        SAXMessageFormatter.formatMessage(null,
                        "schema-already-specified", new Object[] {JAXPConstants.JAXP_SCHEMA_LANGUAGE}));
            else if (attributes.containsKey(JAXPConstants.JAXP_SCHEMA_SOURCE)) {
                throw new ParserConfigurationException(
                        SAXMessageFormatter.formatMessage(null,
                        "schema-already-specified", new Object[] {JAXPConstants.JAXP_SCHEMA_SOURCE}));
        try {
            return new DocumentBuilderImpl(this, attributes, features, fSecureProcess);
        } catch (SAXException se) {
            // Handles both SAXNotSupportedException, SAXNotRecognizedException
            throw new ParserConfigurationException(se.getMessage());
    }It appears to be thread-safe. The 'attributes' and 'features' instances variables are hashtables, which are synchronized. Unless you are modifying DocumentBuilderFactory itself in another thread (say, changing whether it is namespace aware), I do not see any issues with a simple call to newDocumentBuilder().
- Saish

Vector Replacement in Java 1.4 - Is Thread Safety Needed In This Scenario?

I have a Java 1.4 application that queries Database # 1, and builds custom strings used to create records that are inserted into Database # 2.
Right now Vectors are used as a container to temporarily hold query output from Database # 1 while building records going into Database # 2, but I want to convert away from this legacy collection type.
This application does this with a single "worker" thread that is started and monitored by the application main thread. If the main thread detects any exceptions, i.e. a network or any database problem, the application main thread will stop the single worker thread and restart a new single worker thread.
There are several instances of this application running simultaneously on the same server but accessing different test databases. When put into the production environment this application will run on a separate server and there will be only 1 instance of the application running.
I have reviewed numerous forums here and Google results and have not found much specific info that would closely apply to my exact design situation. I did not post any code since this is more of a design question than issue with a specific code snippet.
My question is: In the scenario I described, does thread safety need to be a factor in choosing a new collection type (to replace Vectors) and in building code that accesses this new collection type?

The several instances of the application are all independent JVMs and can't interact with each other directly at all. So there's no thread safety issue there and there never was. So what does that leave you? You've got a single worker thread using the Vector? There's no thread safety issue there either. The only time you have to think about thread safety is when two threads are trying to use the same object.

Issue with Generate Create Script in new ODT 11.1.0.6.10 beta

I've tried this on several tables in my database. I choose Generate Script to ... a file, for a given table it gives me the error message "An error occurred while writing to fil: \nValue was either too large or too smal for an Int32."
(It doesn't matter if I'm in a Oracle database project or some other project.)
Trying to Generate Script To Project... when I'm in a Oracle Database Project, Visual Studio (2005) crashes. It appears to be some overflow exception according to crashinfo:
EventType : clr20r3 P1 : devenv.exe P2 : 8.0.50727.762 P3 : 45716759
P4 : mscorlib P5 : 2.0.0.0 P6 : 461eee3d P7 : 407b P8 : a3
P9 : system.overflowexception
(With ODT 11.1.0.5.10 beta it worked fine dispite the issue discussed in thread: Re: Issue with Generate Create Script in new ODT 11.1.0.5.10 beta
/Tomas

Tried to debug this error and got these exception details. Hope it helps!
/Tomas
System.OverflowException was unhandled
Message="Value was either too large or too small for an Int32."
Source="mscorlib"
StackTrace:
Server stack trace:
at System.Decimal.ToInt32(Decimal d)
at System.Decimal.op_Explicit(Decimal value)
at Oracle.Management.Omo.TableSpaceQuotaDetails.FillTableSpaceQuota(OracleDataReader reader)
at Oracle.Management.Omo.User.FillTableSpaceQuotas(OracleDataReader reader)
at Oracle.Management.Omo.Connection.GetUserCollection(Boolean refresh)
at Oracle.Management.Omo.Connection.GetUsers(Boolean refresh)
at Oracle.Management.Omo.TableSQLGenerator.GetCreateSQLs(OmoObject obj, ArrayList& typeAndNames, Boolean checkRequired, Boolean appendSchemaName)
at Oracle.Management.Omo.TableViewBase.GetCreateSQLs(Boolean appendSchemaName)
at Oracle.VsDevTools.OracleUILDBProjectServices.GenerateCreateScript(OracleUILConnCtx connCtx, String[] objectNames, String objectOwner, OracleUILObjectType objectType)
at Oracle.VsDevTools.OracleUILDBProjectServices.GenerateCreateScriptAsyncMethod(IntPtr ppvObj, OracleUILConnCtx connCtx, String[] objectNames, String objectOwner, OracleUILObjectType objectType, ICollection& scriptText)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
at Oracle.VsDevTools.OracleUILDBProjectServices.GenerateScriptAsyncMethodDelegate.EndInvoke(ICollection& scriptText, IAsyncResult result)
at Oracle.VsDevTools.OracleUILDBProjectServices.OnGenerateScriptAsyncCompletion(IAsyncResult ar)
at System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage(IMessage msg)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

Issue with calling procedure remotely

Hello,
Within the stored procedure, I am calling a procedure remotely but the '@v_remote_db' variable does not resolve:
begin
for i in cur_database_list loop
v_remote_db := i.database_name;
p_trunc_remote_table@v_remote_db; <<<------does not resolve
end loop;
end;
Would work if obsolute value:
p_trunc_remote_table@dev_db <------"works because dev_db is an actually database name and not a variable."
The database link is correctly defined and works.
Question: How to go around using obsolute value? I need to use a variable because the variable v__remote_db resolves to about 50 databases. Thank you.

Duplicate thread:
Re: issue with remote procedure calls
Amiel

Thread safety in FMIS

Can two threads access the same variable in an FMIS application?
I'm collecting a queue (associative array) of values submitted by clients in an FMS App, and using setInterval to call a function which collects the queue at 10-second intervals, reads the values in the array, and sends them to a remote web service. I'm concerned that the first process might be trying to update the queue while the second is trying to use it.
Everywhere I read that FMS apps are single threaded, but I've had some odd results at the web service which seem to indicate lost data. If there is a potential thread safety issue, could it be prevented by wrapping the queue in a sharedObject?

The implementation is a bit more complex then this. When you create a JCD that implements an existing web service (ie a JCD that is started by a connector), eDesigner will create a message driven bean that is triggered by the connector and a stateless session bean that will be called from the message driven bean. This stateless session bean will call your JCD web service method, the receive or the start method.
Because your JCD is hosted in a stateless session bean it will receive all the benefits of the J2EE thread and instance management. If there are multiple JMS messages to process, the application server can create multiple instances of the stateless session bean that hosts your JCd and thereby multiple instances of your JCD class will be created. If these are no longer needed, the application server can destroy them. As stateless session beans are thread safe, you do not need to code your JCD's in a thread safe manner. Of course if you want to access static resources or use singletons then you will need to access these in a threda safe manner from the JCD.
When you JCD's are started by a JMS message (this is when your JCD's implement the JMS receive web service), you can configure in the connectivity map how many instances of your JCD can be started concurrently by the application server. When double clicking the configuration block on the JMS inbound connection you can specify two options:
- Connection Consumer or Serial mode: multiple instances can be started when multiple messages are available or not.
- Server session pool size: how many instances can be created.

Starting issues with iMac 27 i5 quad after crucial RAM expansion

I have read through a few threads regarding issues with crucial RAM upgrades in iMacs but they don't quite match what I am experiencing.
I have installed 2 x 2 GB Crucial RAM (manufacturer 0x80CE) in addition to the pre-installed 4GB. The iMac works fine without any glitches, freezes or crashes. However, when I try to start it up in the morning I can hear the HD starting up and stopping once. The start chime doesn't sound and the display stays black. I take out the 4GB and the computer starts up without any problems. I then switch it off again, install the other 2 RAM again and lo and behold: all works fine. Until the next morning. I do not entirely disconnect the iMac, which is an Apple refurbished machine, I just switch it off.
The first time that happened, I thought it was another problem like USB, bluetooth etc. So I systematically disconnected and reconnected all peripherals, I even used a USB mouse and keyboard and tried to start up from the restore DVD. So I went through all that pain.
If there is an existing thread I would appreciate if you could point me in the right direction because I couldn't find anything like this on this forum.

Did you test all 4 modules one at time in a top slot as suggested, to see if they are all working?
● If any one of the modules fail to properly boot the iMac, factory or crucial then do not reinstall it into the iMac.
● If all of the modules individually boot the iMac, then try reinstalling the Crucial in the top slots, the factory in the bottom slots and Startup the iMac reseting the PRAM.
http://support.apple.com/kb/HT1379
+1. Locate the following keys on the keyboard: Command, Option, P, and R. You will need to hold these keys down simultaneously in step 4.+
+2. Turn on the computer.+
+3. Press and hold the Command-Option-P-R keys. You must press this key combination before the gray screen appears.+
+4. Hold the keys down until the computer restarts and you hear the startup sound for the second time.+
+5. Release the keys.+
Now then if the iMac is not booting from all 8GB of RAM, then there is a compatibility problem with the Crucial RAM and you need to contact Crucial and tell them that there Ram is not working with your Factory RAM.
Why would you only want RAM in the bottom slots, I thought the idea here was to upgrade from 4 to 8GB?
The article clearly states that the iMac will not boot with only 1 module in a bottom slot.
http://support.apple.com/kb/HT3918

Thread safety with newDocumentBuilder()

Hello,
I have the following class 'ParserService'. Just one instance of this class exists, and it's created in the servlet init method calling "new ParserService()".
After this, all incoming requests (threads executing service method) call the 'parse' method
public class ParserService
private DocumentBuilderFactory dbfDom;
// Constructor.
public ParserService()
this.dbfDom = DocumentBuilderFactory.newInstance();
this.dbfDom.setNamespaceAware(true);
this.dbfDom.setCoalescing(true);
// ---------------- DOM PARSER ------------------------------------------------------------------------------
public Document parse(String strDocument) throws ProxyServletException
try
   return (this.dbfDom.newDocumentBuilder().parse(new InputSource(new StringReader(strDocument))));
catch (ProxyServletException pse) { throw pse; }
catch (Exception e)                { throw new ProxyServletException(GenericConstants.PARSER_PARSE, e); }
}The question is if 'newDocumentBuilder()' is thread safe. Can I call the 'newDocumentBuilder()' method from different threads using the only factory 'this.dbfDom'?
Thanks in advance,
Joan.

     * Creates a new instance of a {@link javax.xml.parsers.DocumentBuilder}
     * using the currently configured parameters.
    public DocumentBuilder newDocumentBuilder()
        throws ParserConfigurationException
        /** Check that if a Schema has been specified that neither of the schema properties have been set. */
        if (grammar != null && attributes != null) {
            if (attributes.containsKey(JAXPConstants.JAXP_SCHEMA_LANGUAGE)) {
                throw new ParserConfigurationException(
                        SAXMessageFormatter.formatMessage(null,
                        "schema-already-specified", new Object[] {JAXPConstants.JAXP_SCHEMA_LANGUAGE}));
            else if (attributes.containsKey(JAXPConstants.JAXP_SCHEMA_SOURCE)) {
                throw new ParserConfigurationException(
                        SAXMessageFormatter.formatMessage(null,
                        "schema-already-specified", new Object[] {JAXPConstants.JAXP_SCHEMA_SOURCE}));
        try {
            return new DocumentBuilderImpl(this, attributes, features, fSecureProcess);
        } catch (SAXException se) {
            // Handles both SAXNotSupportedException, SAXNotRecognizedException
            throw new ParserConfigurationException(se.getMessage());
    }It appears to be thread-safe. The 'attributes' and 'features' instances variables are hashtables, which are synchronized. Unless you are modifying DocumentBuilderFactory itself in another thread (say, changing whether it is namespace aware), I do not see any issues with a simple call to newDocumentBuilder().
- Saish

Thread Safety Issue with DOM

Similar Messages

Maybe you are looking for