Session bean behavior when user creates new browser window......

[Al Willingham <ga...@cox.net>]

Suppose a user chooses to create a new browser window during a session
with a session bean, submits the data in the new window, then goes back
to the old and submits the old data that has not been refreshed. Is this
one of those things that the user gets what they deserve for being so
brain dead, or is there some check that I can perform to prevent this?

Thanks
Al



-- 
Al Willingham <ga...@cox.net>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Session bean behavior when user creates new browser window......

[Al Willingham <ga...@cox.net>]

It seems like that requires coordination between the DAO and bean. Every
time the bean changes, you coordinate with the DAO???

I'm thinking that the session bean captures data until an appropriate
moment, then commits to the database through the DAO. Saves expensive
trips to the DB.  

Maybe an example????

Hmmm, there is some mechanism that manages the time settings of the
session bean. Every time the bean is sent back to the server, the "bean
time" is updated to the current time. I wonder if this could be tweaked
so some kind of flag could be set with each specific bean indicating the
"state" of the bean. Maybe a hidden form field with an int, with a copy
of the int stored in the mechanism, associated with the bean. Session
bean sent to server, increment both. Thus, if the "old" browser windows
submits, its int is less than the current and would be rejected.

Thoughts?? Or am I making something harder than it should be?

On Mon, 2003-03-31 at 20:31, Scott Barr wrote:
> Hi Al
> 
> I have addresses the dirty update problem by creating a DAO layer that
> checks an int field at the time of update to the database. If the value
> is different, someone updated it. No long locks, no worrying about
> sessions....
> 
> Very simple, but very effective.
> 
> Scott Barr
> www.exergonic.com.au
> 
> 
> On Tue, 2003-04-01 at 12:52, Al Willingham wrote:
> 
> > >From past experience "dirty data" management is usually handled by the
> > database. Locking record when data is retrieved for update, etc. 
> > 
> > Something that comes to mind is when the record is retrieved for update,
> > lock the record, note the session bean id and set some value indicating
> > state. ie update complete or not. Check value and session bean id before
> > update commit, if match, do it. If the "old" window tries to update
> > after the new has changed the state, then it would be rejected.
> > 
> > Seems like I read some of this stuff in J2EE and could be managed more
> > easily by an app server????
> > 
> > If I have to start managing this, would it be time to start looking at a
> > J2EE implementation of my app?
> > 
> > Buuut, an earlier thread mentioned something about a counter in the
> > session, maybe increment counter for each session update/change. If some
> > session has lower value, reject.???
> > 
> > 
> > 
> > On Mon, 2003-03-31 at 18:10, V. Cekvenich wrote:
> > > In event driven programing the user is in charge of program flow.
> > > As opposed to procedural programing where programmer is in charge (In 
> > > COBOL you had menu choice 1-5).
> > > So you have to check.
> > > You have to consider most contingencies.
> > > 
> > > A good practice is to bean.save() on any submit. (keep the session small 
> > > also).
> > > 
> > > If the bean saves, good!, continue.
> > > If the bean does not save because xhyz is missing, or wrong step, then 
> > > you forward user to the appropriate place.
> > > 
> > > See how action/controller comes in handy?
> > > 
> > > It is a bad practice to have several steps and save at the "end" of 
> > > *YOUR* idea of the flow.
> > > Each "step" is an individual event/submit that should be each processed 
> > > discrete.
> > > 
> > > In your case, you have "dirty" data, and you have to decide is this OK 
> > > to save. (If you do not know about dirty writes issues, then you should 
> > > just save based on primary key, and save the dirty data). If this is a 
> > > problem, you have to make a longer where clause based on your bus. reqs.
> > > Then fail the save, and handle in controler.
> > > 
> > > hth,
> > > 
> > > .V
> > > 
> > > 
> > > Al Willingham wrote:
> > > > Suppose a user chooses to create a new browser window during a session
> > > > with a session bean, submits the data in the new window, then goes back
> > > > to the old and submits the old data that has not been refreshed. Is this
> > > > one of those things that the user gets what they deserve for being so
> > > > brain dead, or is there some check that I can perform to prevent this?
> > > > 
> > > > Thanks
> > > > Al
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
-- 
Al Willingham <ga...@cox.net>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Session bean behavior when user creates new browser window......

[Scott Barr <sc...@exergonic.com.au>]

Hi Al

I have addresses the dirty update problem by creating a DAO layer that
checks an int field at the time of update to the database. If the value
is different, someone updated it. No long locks, no worrying about
sessions....

Very simple, but very effective.

Scott Barr
www.exergonic.com.au


On Tue, 2003-04-01 at 12:52, Al Willingham wrote:

> >From past experience "dirty data" management is usually handled by the
> database. Locking record when data is retrieved for update, etc. 
> 
> Something that comes to mind is when the record is retrieved for update,
> lock the record, note the session bean id and set some value indicating
> state. ie update complete or not. Check value and session bean id before
> update commit, if match, do it. If the "old" window tries to update
> after the new has changed the state, then it would be rejected.
> 
> Seems like I read some of this stuff in J2EE and could be managed more
> easily by an app server????
> 
> If I have to start managing this, would it be time to start looking at a
> J2EE implementation of my app?
> 
> Buuut, an earlier thread mentioned something about a counter in the
> session, maybe increment counter for each session update/change. If some
> session has lower value, reject.???
> 
> 
> 
> On Mon, 2003-03-31 at 18:10, V. Cekvenich wrote:
> > In event driven programing the user is in charge of program flow.
> > As opposed to procedural programing where programmer is in charge (In 
> > COBOL you had menu choice 1-5).
> > So you have to check.
> > You have to consider most contingencies.
> > 
> > A good practice is to bean.save() on any submit. (keep the session small 
> > also).
> > 
> > If the bean saves, good!, continue.
> > If the bean does not save because xhyz is missing, or wrong step, then 
> > you forward user to the appropriate place.
> > 
> > See how action/controller comes in handy?
> > 
> > It is a bad practice to have several steps and save at the "end" of 
> > *YOUR* idea of the flow.
> > Each "step" is an individual event/submit that should be each processed 
> > discrete.
> > 
> > In your case, you have "dirty" data, and you have to decide is this OK 
> > to save. (If you do not know about dirty writes issues, then you should 
> > just save based on primary key, and save the dirty data). If this is a 
> > problem, you have to make a longer where clause based on your bus. reqs.
> > Then fail the save, and handle in controler.
> > 
> > hth,
> > 
> > .V
> > 
> > 
> > Al Willingham wrote:
> > > Suppose a user chooses to create a new browser window during a session
> > > with a session bean, submits the data in the new window, then goes back
> > > to the old and submits the old data that has not been refreshed. Is this
> > > one of those things that the user gets what they deserve for being so
> > > brain dead, or is there some check that I can perform to prevent this?
> > > 
> > > Thanks
> > > Al
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Session bean behavior when user creates new browser window......

[Al Willingham <ga...@cox.net>]

>>From past experience "dirty data" management is usually handled by the
database. Locking record when data is retrieved for update, etc. 

Something that comes to mind is when the record is retrieved for update,
lock the record, note the session bean id and set some value indicating
state. ie update complete or not. Check value and session bean id before
update commit, if match, do it. If the "old" window tries to update
after the new has changed the state, then it would be rejected.

Seems like I read some of this stuff in J2EE and could be managed more
easily by an app server????

If I have to start managing this, would it be time to start looking at a
J2EE implementation of my app?

Buuut, an earlier thread mentioned something about a counter in the
session, maybe increment counter for each session update/change. If some
session has lower value, reject.???



On Mon, 2003-03-31 at 18:10, V. Cekvenich wrote:
> In event driven programing the user is in charge of program flow.
> As opposed to procedural programing where programmer is in charge (In 
> COBOL you had menu choice 1-5).
> So you have to check.
> You have to consider most contingencies.
> 
> A good practice is to bean.save() on any submit. (keep the session small 
> also).
> 
> If the bean saves, good!, continue.
> If the bean does not save because xhyz is missing, or wrong step, then 
> you forward user to the appropriate place.
> 
> See how action/controller comes in handy?
> 
> It is a bad practice to have several steps and save at the "end" of 
> *YOUR* idea of the flow.
> Each "step" is an individual event/submit that should be each processed 
> discrete.
> 
> In your case, you have "dirty" data, and you have to decide is this OK 
> to save. (If you do not know about dirty writes issues, then you should 
> just save based on primary key, and save the dirty data). If this is a 
> problem, you have to make a longer where clause based on your bus. reqs.
> Then fail the save, and handle in controler.
> 
> hth,
> 
> .V
> 
> 
> Al Willingham wrote:
> > Suppose a user chooses to create a new browser window during a session
> > with a session bean, submits the data in the new window, then goes back
> > to the old and submits the old data that has not been refreshed. Is this
> > one of those things that the user gets what they deserve for being so
> > brain dead, or is there some check that I can perform to prevent this?
> > 
> > Thanks
> > Al
> > 
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
-- 
Al Willingham <ga...@cox.net>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Session bean behavior when user creates new browser window......

["V. Cekvenich" <vC...@baseBeans.com>]

In event driven programing the user is in charge of program flow.
As opposed to procedural programing where programmer is in charge (In 
COBOL you had menu choice 1-5).
So you have to check.
You have to consider most contingencies.

A good practice is to bean.save() on any submit. (keep the session small 
also).

If the bean saves, good!, continue.
If the bean does not save because xhyz is missing, or wrong step, then 
you forward user to the appropriate place.

See how action/controller comes in handy?

It is a bad practice to have several steps and save at the "end" of 
*YOUR* idea of the flow.
Each "step" is an individual event/submit that should be each processed 
discrete.

In your case, you have "dirty" data, and you have to decide is this OK 
to save. (If you do not know about dirty writes issues, then you should 
just save based on primary key, and save the dirty data). If this is a 
problem, you have to make a longer where clause based on your bus. reqs.
Then fail the save, and handle in controler.

hth,

.V


Al Willingham wrote:
> Suppose a user chooses to create a new browser window during a session
> with a session bean, submits the data in the new window, then goes back
> to the old and submits the old data that has not been refreshed. Is this
> one of those things that the user gets what they deserve for being so
> brain dead, or is there some check that I can perform to prevent this?
> 
> Thanks
> Al
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org