Hi,

how does this interact with the transparent thread handling in an
EJB-Container.
In such a situation, when the container handles the threads that use my
classes, do I have to fear dead lock situations?

I think the only case where there could be a problem is when we call any
bean method inside the logging-call, which could be the case if the message
itself performs such a call to be evaluated.
E.g:
logger.info("Withdrawing " + amount + " $ from account " +
anotherBean.getAccountName(id));

The EJB-Spec prohibits 'the use of thread synchronization primitives', but
explains that this is due to the fact that the container may distribute my
beans over more than one address spaces. In that case we wouldn't have a
problem since we would als have more than one category hierarchies.

Any comment on that?


> -----Original Message-----
> From: Jon Skeet [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, September 06, 2001 3:01 PM
> To:   LOG4J Users Mailing List
> Subject:      RE: Logging in a Multi threaded environment
> 
> > Currently we are considering log4j for our application 
> > logger and so I have tried out the basic features of log4j ....
> 
> > But i have a doubt when i try to log in a multithreaded 
> > environment...DOES log4j PROVIDE A SYNCHRONIZED LOGGING MECHANISM?? 
> 
> Yes - or rather, it depends on the appender in question, but any
> appender inheriting from AppenderSkeleton (which most will) synchronize
> there.
> 
> > say a thread A is logging some message in a class at 
> > the same time when another thread of the same class is 
> > also busy logging!! In such an event my HO is that since 
> > the Category object that they share is a static one with 
> > the same name, messages from both the threads would go to 
> > the same Category object..am i right?
> 
> Yes.
> 
> > Also, consider a situation wherein my thread A has a big 
> > message and has called its cat.info(message)...similarly 
> > thread B had called its cat.info(message) but has only a 
> > smaller message. In such a case, which will appear first, 
> > say in my file if i use a FileAppender, message of thread A or B???
> 
> Whichever gets to the appender.doAppend() first.
> 
> Jon
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to