• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread safe J2ee applcaition

 
Mary Wallace
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know this is a vast topic. Single thread model is deprecated and also not thread safe. Using synchronization will affect performance. Is this book covering these issues. ?
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think the book will discuss about the threading issue in J2EE in specific... But this sample chapter discusses about the "Can You Avoid Synchronization?" question... It's a great chapter... I've already skimmed through that chapter...

Moreover, Chapter-14(Thread Performance) is also interesting... I hope we can expect more about the performance issue of synchronization in that chapter as well...
 
Mary Wallace
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I went thr that chapter

the book says
What�s happening in our examples with atomic variables is that there is no free lunch:
the code avoids synchronization, but it pays a potential penalty in the amount of work
it performs. You can think of this as �optimistic synchronization� (to modify a term
from database management): the code grabs the value of the protected variable assuming
that no one else is modifying it at the moment. The code then calculates a new
value for the variable and attempts to update the variable. If another thread modified
the variable in the meantime, the update fails and the code must restart its procedure
(using the newly modified value of the variable).



Using atomic class doesnt mean that that is good performance practise. Moreover you can use that only with j2se 5.0?
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mary Wallace:
I know this is a vast topic. Single thread model is deprecated and also not thread safe.


Single thread model is not deprecated and I wonder how a single thread can be not thread safe .


Using synchronization will affect performance. Is this book covering these issues. ?

The latest JVMs are very very optimized on synchronization, so if used correct the time penalties will be minimal.

./pope
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ali Pope:

Single thread model is not deprecated and I wonder how a single thread can be not thread safe .

./pope


I think he meant Servlet Spec's SingleThreadedModel interface is deprecated now.
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I remember well these atomic classes are available in concurrent library by Doug Lea for previous JDK 1.5

./pope
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by karthik Guru:


I think he meant Servlet Spec's SingleThreadedModel interface is deprecated now.


... than I would say not recomended and I also would say that writting a thread safe servlet is quite easy. You just need to respect the general threading recommendations.

./pope
 
sunitha reghu
Ranch Hand
Posts: 937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are those general threading recommendations?

Originally posted by Ali Pope:


... than I would say not recomended and I also would say that writting a thread safe servlet is quite easy. You just need to respect the general threading recommendations.

./pope
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Writting Threadsafe Servlets

./pope
 
Mary Wallace
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this article

A common alternative is to use a reader/writer lock that allows many requests to read the cache (all readers share one synchronization lock), at the expense of starving a writer who will rarely gain access to the lock during peak usage time. The reader/writer lock technique works well when there are more readers than writers. Although the reader/writer lock can be a middle ground between the opposing requirements, other tricks can be utilized to achieve both goals. If memory is in abundance, you can cache data in memory that is not shared between users. Each user will have a cache to reduce the expense of data lookup, at the cost of additional per-user memory consumption. This technique is known as "zero shared memory" optimization. The coding techniques that can be employed to achieve high performance are continuing to grow


im conused with the term reader/writer lock
 
Mary Wallace
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When inserting a large number of records to db using batchprocess how the make
the whole process tread safe?
Is the synchornization is the correct approch.
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the author want to suggest the of a lock object for synchronization. This lock would be acquired by all readers and writers before performing an operation.

./pope
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mary Wallace:
When inserting a large number of records to db using batchprocess how the make
the whole process tread safe?
Is the synchornization is the correct approch.


I think this is something different and the solution must used transaction level. You can read more starting from here:
Transactions

./pope
 
Henry Wong
author
Sheriff
Posts: 22524
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Years ago... when we released the first edition of Java Threads. The examples were mostly just applications. The exception was the first few chapters, which used applets... to be blunt, we ended up with a ton of complaints. The argument went, "we are here to learn threads, not applets". I don't even want to imagine what would have happened if we used servlets, EJBs, or Jini components, as examples...

Henry
 
Henry Wong
author
Sheriff
Posts: 22524
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moreover, Chapter-14(Thread Performance) is also interesting... I hope we can expect more about the performance issue of synchronization in that chapter as well...


The performance chapter does two things... First, it goes through a minor discussion on how to measure performance. Second, and more interesting, are the performance studies.

The covered topics are... Performance differences of the different collection types -- with emphasis on synchronization. Performance of synchronization when contended, when not contended, when using atomic variables. Performance of thread creation vs thread pools.

The studies cover single threaded, 2 threads, and many threads, for Windows, Linux, and Solaris.

Henry
 
Henry Wong
author
Sheriff
Posts: 22524
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But this sample chapter discusses about the "Can You Avoid Synchronization?" question... It's a great chapter... I've already skimmed through that chapter...


Thanks. It is my favorite chapter... I happened to mention it to my editor, without thinking that it would become the free sample chapter.

However, this is not a basic discussion about atomic variable. It is a discussion on optimistic locking techniques, with the emphasis on minimizing (spelling?) synchronization. Atomic variables are just introduced and used in this chapter.

In terms of difficulty, it is like a speed bump in the middle of the book. We even had discussions on whether it should be moved to a later chapter... but it, along with chapter 6, just fit well where it is. I just hope that the difficulty doesn't turn off many readers.

Henry
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!