• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Thread safe J2ee applcaition

 
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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. ?
 
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Writting Threadsafe Servlets

./pope
 
Mary Wallace
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author
Posts: 23919
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 23919
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 23919
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Friends help you move. Good friends help you move bodies. This tiny ad will help:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic