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.

Similar Messages

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.

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...

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.

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.

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.

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.

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

Dumb question about Thread Safety in Servlets

Hi all
I wrote this Client API for sending requests and receiving responses to / from a multivalue database. The API is called by my Servlet. Now it seems my API is not thread safe because when several people open up the servlet at the same time, the API gets totally confused. When the API calls are inside a synchronized(){} it works just fine, but obviously at a big performance hit. Is that the wrong way of doing it??
However when I was doing the ACID test locally on my machine, by opening two command prompts and excuting the same java program (with the same code in it as the servlet, but standalone) my API worked just fine. How come?
Any insights appreciated as I am just learning about thread safety now (the hard way :-( )
cheers
Dejan

Does this help
Are you using one connection to the database shared by all instances
of your servlet
And is this connection create in the init method of the servlet and stored
in the servlet context.
Problem 4 people try and use your servlet at the same time, each servlet trys to
create a connection to the database and then store it in the servlet context and
this causes a problem.
Solution create a listener to create the connection and store it in the servlet context
when the servlet is created.
If this is your problem it is not advisable to use only one connection to the db
try using db pooling

Java Bean Thread Safety

I've been using JavaBeans for years now, and have read at least 30 different texts and online resources about using Java beans in JSPs. But in every single one of them, they are ambiguous and non-committal about how to properly use them to avoid Thread-Safety problems in a multithreaded (web server) environment. Are there any true Java gurus out there who know how to do so in JSPs?
Specifically, when you use the <jsp:useBean> tag, that tag automatically binds an instance of your bean to the PageContext object. Since the PageContext object is shared by many threads, wouldn't this automatically make all of the Java Bean's properties vulnerable for thread problems? Since the pageContext is shared between threads, wouldnt one have to declare every one of the bean's setters and getters as "synchronized", to prevent one thread overwriting another's values?
I ask because in many texts, they make a vague suggestion "be sure to write your beans thread-safe"--but provide no concrete answer as to how (the level at which to declare 'synchronized'). But in all their code examples, I have never once, in all these years, seen the word "synchronized".
How is this possible? Wouldn't the bean, as bound to the thread-shared pageContext object, be completely exposed to thread corruption, with multiple threads simultaneously calling its methods?
Can someone supply some code snippets showing the thread-safe way to use JavaBeans (i.e., where to synchronize)

PageContext is shared by many threads?
Not at one time, I'm pretty certain of that.
From the API: A PageContext instance is obtained by a JSP implementation class by calling the JspFactory.getPageContext() method, and is released by calling JspFactory.releasePageContext().
The to me suggests the contract that a PageContext can only be in use by on one JSP page at a time. As far as I am concerned, pageContext can be treated like a "local variable" to a jsp page.
The contents of the pageContext object are maybe a different story, but we'll get to that.
The things to worry about with thread safety are the same as they are for servlets.
1 - Class attributes are not threadsafe. ie variables declared within <%! %> signs
2 - Session attributes are potentially not threadsafe if the user makes two quick requests in a row (handling two requests for the same session)
3 - Application attributes are never threadsafe as any currently running request can access them. Most Application level attributes I treat as read only (kinda like Singleton access)
I don't see the need to go overboard declaring everything "synchronized". In fact I think it would be hugely detrimental.

Please Explain SRV.2.3.3.3 Thread Safety

SRV.2.3.3.3 Thread Safety
Implementations of the request and response objects are not guaranteed
to be thread safe. This means that they should only be used within the
scope of the request handling thread. References to the request and
response objects must not be given to objects executing in other
threads as the resulting behavior may be nondeterministic.
My question is does a scenario arise often in practice? And if so,
could you let me know when.Basically what precautions should I take regarding this clause.

My question is does a scenario arise often in practice?No, because people are usually smart enough not to access request and response objects from several threads :-)
And if so, could you let me know when.If you access request and response objects from other threads.
Basically what precautions should I take regarding this clause.Don't access request and response objects from other threads. Don't store them in any static variable, or store them in some data structure where they can end up being accessed from random places.
As much as possible, access request and response only in the servlet. That is smart anyway: you don't want to pass them to your "business code" because that makes the business code less reusable and harder to test.
Usually this pretty much takes care of itself. There is rarely need to store the objects anywhere. One trap is declaring fields in servlets and storing something there. Never have fields in servlets, it is a bad idea because it is usually thread unsafe (except static final constants).

What are the thread safety requirements for container implementation?

I rarely see in the TopLink documentation reference to thread safety requirements and it’s not different for container implementation.
The default TopLink implementation for:
- List is Vector
- Set is HashSet
- Collection is Vector
- Map is HashMap
Half of them are thread safe implementations List/Collection and the other half is not thread safe Set/Map.
So if I choose my own implementation do I need a thread safe implementation for?
- List ?
- Set ?
- Collection ?
- Map ?
Our application is always reading and writing via UOW. So if TopLink synchronize update on client session objects we should be safe with not thread safe implementation for any type; does TopLink synchronize update on client session objects?
The only thing we are certain is that it is not thread safe to read client session object or read read-only UOW object if they are ever expired or ever refreshed.
We got stack dump below in an application always reading and writing objects from UOW, so we believe that TopLink doesn’t synchronize correctly when it’s updating the client session objects.
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449)
at java.util.AbstractList$Itr.next(AbstractList.java:420)
at oracle.toplink.internal.queryframework.InterfaceContainerPolicy.next(InterfaceContainerPolicy.java:149)
at oracle.toplink.internal.queryframework.ContainerPolicy.next(ContainerPolicy.java:460)
at oracle.toplink.internal.helper.WriteLockManager.traverseRelatedLocks(WriteLockManager.java:140)
at oracle.toplink.internal.helper.WriteLockManager.acquireLockAndRelatedLocks(WriteLockManager.java:116)
at oracle.toplink.internal.helper.WriteLockManager.checkAndLockObject(WriteLockManager.java:349)
at oracle.toplink.internal.helper.WriteLockManager.traverseRelatedLocks(WriteLockManager.java:144)
at oracle.toplink.internal.helper.WriteLockManager.acquireLockAndRelatedLocks(WriteLockManager.java:116)
at oracle.toplink.internal.helper.WriteLockManager.checkAndLockObject(WriteLockManager.java:349)
at oracle.toplink.internal.helper.WriteLockManager.traverseRelatedLocks(WriteLockManager.java:144)
at oracle.toplink.internal.helper.WriteLockManager.acquireLockAndRelatedLocks(WriteLockManager.java:116)
at oracle.toplink.internal.helper.WriteLockManager.acquireLocksForClone(WriteLockManager.java:56)
at oracle.toplink.publicinterface.UnitOfWork.cloneAndRegisterObject(UnitOfWork.java:756)
at oracle.toplink.publicinterface.UnitOfWork.cloneAndRegisterObject(UnitOfWork.java:714)
at oracle.toplink.internal.sessions.UnitOfWorkIdentityMapAccessor.getAndCloneCacheKeyFromParent(UnitOfWorkIdentityMapAccessor.java:153)
at oracle.toplink.internal.sessions.UnitOfWorkIdentityMapAccessor.getFromIdentityMap(UnitOfWorkIdentityMapAccessor.java:99)
at oracle.toplink.internal.sessions.IdentityMapAccessor.getFromIdentityMap(IdentityMapAccessor.java:265)
at oracle.toplink.publicinterface.UnitOfWork.registerExistingObject(UnitOfWork.java:3543)
at oracle.toplink.publicinterface.UnitOfWork.registerExistingObject(UnitOfWork.java:3503)
at oracle.toplink.queryframework.ObjectLevelReadQuery.registerIndividualResult(ObjectLevelReadQuery.java:1812)
at oracle.toplink.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneNormally(ObjectBuilder.java:455)
at oracle.toplink.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:419)
at oracle.toplink.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:379)
at oracle.toplink.queryframework.ObjectLevelReadQuery.buildObject(ObjectLevelReadQuery.java:455)
at oracle.toplink.queryframework.ObjectLevelReadQuery.conformIndividualResult(ObjectLevelReadQuery.java:622)
at oracle.toplink.queryframework.ReadObjectQuery.conformResult(ReadObjectQuery.java:339)
at oracle.toplink.queryframework.ReadObjectQuery.registerResultInUnitOfWork(ReadObjectQuery.java:604)
at oracle.toplink.queryframework.ReadObjectQuery.executeObjectLevelReadQuery(ReadObjectQuery.java:421)
at oracle.toplink.queryframework.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:811)
at oracle.toplink.queryframework.DatabaseQuery.execute(DatabaseQuery.java:620)
at oracle.toplink.queryframework.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:779)
at oracle.toplink.queryframework.ReadObjectQuery.execute(ReadObjectQuery.java:388)
at oracle.toplink.queryframework.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:836)
at oracle.toplink.publicinterface.UnitOfWork.internalExecuteQuery(UnitOfWork.java:2604)
at oracle.toplink.publicinterface.Session.executeQuery(Session.java:993)
at oracle.toplink.publicinterface.Session.executeQuery(Session.java:950)

Hi Lionel,
As a general rule of thumb, the ATI Rage 128 Pro will not support a 20" LCD. That being said, there are reports of it doing just that (possibly the edition that went into the cube).
I'm not that familiar with the ins and outs of the Cube, so I can't give you authoritative information on it.
A good place to start looking for answers is:
http://cubeowner.com/kbase_2/
Cheers!
Karl

New tabs vanish when I view another one, MOST URL's vanish after a second and that is a safety issue if you can see if you are on the right page!

A while ( couple weeks ) before the last update and change I noticed my URL's were vanishing a second after I arrived on a page. Not all URL's but most. This is a safety issue if I can't see I'm on the right page and have not been diverted.
ALSO, I can't copy them to send a link via email if they aren't there! I found a way in the old FF click down list, but even that feature is gone on this new version! This needs fixed at once.
AND when I make a new tab it vanishes! Or worse does not display like a tab. I can't go back and forth between pages if the tab vanishes. This started with the last FF update and change. This is poor design!!! When I updated the restore previous session grayed out. All my tabs were gone and I don't have them all in history. I was researching some things and it was important, now I can't remember them all. This is not a good thing!
Unless you pin all your tabs immediately they will vanish??????? Stupid design. It does not even show the new tab for THIS page!!! "but is does show your URL....hmmmmm"
What is the reason for having an arrow go through open tabs if they vanish???
PLEASE FIX THIS or I'll have to change browsers, I'll have no choice. How can you do anything if FF erases your URL's or tabs!

Hey Fox1User,
Thank you for your message. I believe that this will happen when you have a dark theme applied to the new version of Firefox. It has been resolved in the 29.0.1 update that went out yesterday and would love to hear if this has improved the issue for you. I understand that the tabs are disappearing and it sounds like they may be blending into the tab bar.
However! if this is not the case, can you please show a screenshot of the tabs [[How do I create a screenshot of my problem?]] after trying to produce this in Safe Mode [[Troubleshoot Firefox issues using Safe Mode]].
I hope we find the culprit, looking forward to your reply.
I also noticed you have 4 versions of Flash installed.

MacBook Pro Health and safety issue: Potential Burn during normal use

Hi,
I am not a complainer. I worked for Apple of 6+ years and have had a top of the line Apple Notebook since Apple created the concept of the laptop notebook.
I recently experienced a 3rd degree burn using my MacBook Pro that I think Apple needs to warn folks about:
MacBook Pro 17"
Machine Model: MacBookPro1,2
CPU Type: Intel Core Duo
Number Of Cores: 2
CPU Speed: 2.16 GHz
L2 Cache (shared): 2 MB
Memory: 2 GB
Bus Speed: 667 MHz
Boot ROM Version: MBP12.0061.B00
Serial Number: ()
SMC Version: 1.5f10
Sudden Motion Sensor:
State: Enabled
I had my laptop on my lap. I was wearing shorts. It noticed that it was warm on my leg where the left side of the MacBook Pro was touching my leg, but it didn't create a reflex pain response.
Upon completing my session, when I closed the machine and put it away, I noticed a 1 inch x .75 inch blister on my leg where it had been touching the MacBook/Pro; and it has turn out to be a significant burn.
I checked all the documentaiton that came with my MacBook Pro and there was no warning about the potential of this situation.
I recommend that Apple let owners know, perhaps through an email or a popup when they visit the Apple site. Lastly, when I encountered this issue, I wasn't running any high performance, compute bound applications. It was email. So, I have to believe that it is possible to detect wait states within the processes running and take the processors to a low power mode of operation when they are not performing actual work. Am I out in left field here?
I want Apple to be successful. I haven't heard of a similar complaint on any of the high performance PC's at work. Beyond a Health and Safety issue, this is also a reputation issue. Better to face into the storm and honestly deal with this issue.
A slightly crisp, but loyal, MacBook Pro user.
Mike Doherty
MacBook Pro Mac OS X (10.4.5) Potential Health and Safety Issue- 3rd degreee burn potential under normal use

Mike... I do sympathize with your situation but let me correct you:
I recently experienced a 3rd degree burn using my
MacBook Pro
Do you know what a 3rd degree burn is? A 3rd degree burn involves the dermis, and is full thickness involving the subcutaneous tissues and fat underneath your skin layers. This is something that usually happens when man meets fire, electrocution, and chemical burns. A 3rd degree burn is not typically achieved by a simple transfer of energy by conduction, unless extreme heat for an extended period of time.
I had my laptop on my lap. I was wearing shorts. It
noticed that it was warm on my leg where the left
side of the MacBook Pro was touching my leg, but it
didn't create a reflex pain response.
Reflex pain response? Don't try to make up medical terminology. You didn't feel it much like you don't feel the sun when you get a sunburn initially... your skin slowly adjusted to the temperature, and at some point the heat increased over the threshold of which causes damage. You should have gone to the doctor if you were overly concerned.
Upon completing my session, when I closed the machine
and put it away, I noticed a 1 inch x .75 inch
blister on my leg where it had been touching the
MacBook/Pro; and it has turn out to be a significant
burn.
You're right, if you have a 1inch by almost 1 inch heat related blister on your leg, it is bad, nothing that I would consider significant. That is less then 1% of your body, probably about 0.25% to 0.5%, and only a 2nd degree burn. Your most significant complication would be a local skin infection.
I checked all the documentaiton that came with my
MacBook Pro and there was no warning about the
potential of this situation.
Actually... I'd hate to call you a liar, but I'm pretty sure that it does warn about burns.
To confirm this, apple has also information online:
http://docs.info.apple.com/article.html?artnum=30612
I recommend that Apple let owners know, perhaps
through an email or a popup when they visit the Apple
site.
They do... link above.
Lastly, when I encountered this issue, I wasn't
running any high performance, compute bound
applications. It was email. So, I have to believe
that it is possible to detect wait states within the
processes running and take the processors to a low
power mode of operation when they are not performing
actual work. Am I out in left field here?
No, you're definitely not. Here's where I start to agree with you. For the computer to heat up that much, when not doing things like rendering video is abnormal, and you deserve to have apple check out your computer. I think you should contact them on this concern.
I want Apple to be successful. I haven't heard of a
similar complaint on any of the high performance PC's
at work. Beyond a Health and Safety issue, this is
also a reputation issue. Better to face into the
storm and honestly deal with this issue.
It's harder for other manufacturers... our computers are aluminum, designed to disperse the heat. Technically they are considered "portables" not laptops, but I don't get into that argument because I disagree with the word "portable"... it's meant to work on your lap, and if you can't comfortably using regular apps, you deserve an answer.
A slightly crisp, but loyal, MacBook Pro user.
Hey, at least you're taking it with some humor. It's a shame you had to get hurt as a result of your computer. If I were you I would have gone to your Primary Care Physician, documented the burn, and returned your computer for a new one, and for something say, a free iPod for your pain.
Sorry you got hurt, I think you should have your heat issue professionally investigated through apple care

THREAD SAFETY ISSUE OF SERVLET

Similar Messages

Maybe you are looking for