• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

what is meant by persistant state

 
Ranch Hand
Posts: 237
MyEclipse IDE Firefox Browser Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
will you please explain me the following sentence.
an application can concurrently access the same persistent state in two different sessions.
how ever an instance of persistance class is never shared between two sessions.
 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Whatever im trying to explain it's according to my knowledge;
You can access more than one task at a time it's called as concurrently access. But in this accessing each task during the accessing it's session is different; but they could not shares each others session attribute whule they are concurrently running.
 
Ranch Hand
Posts: 200
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That means that two different transaction can access the same database row and modify it. The one who saves first "wins". The second one has to fail. (If designed correctly...) Thats optimistic locking. If this situation does not happen very often you use optimistic locking to avoid database locks.
The app server guarantees that every user gets his own session and his "own" state of the database row to modify it. No session can see changes that aren't persisted yet. If sessions could share their objects this couldn't be guaranteed.
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Whenever you buy the movie tickets there could be scenarios where you see multiple queues for the ticket window.It exactly works like a session in the database persistence world.If you have booked the seat first you will get that seat and to other person even if it was showing available when he initially started the booking has to leave that seat.It is one scenario when you have mutually exclusive access to the resources.

Apart from that lets say you work on one file from source code repository and you have made some changes to this.Same time other user have made some changes to the file and checked in the code before you submitted your changes to that file.Repository always ask you to either merge your changes or drop your changes to the same file whenever you try to submit your changes..These all are classic examples of multiple session used for accessing the same resources.Hope this helps

 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic