Removing nested bean collections in session scope.......

2003-04-03 Thread Al Willingham
Hi,

Thanks for considering this...

I'm really stumped. I have several layers of collections, ie, a nest of
beans inside a nested bean in an actionForm with session scope. When I
am finished with the collections, I call my own reset method and set the
top level collection to null. I am not overriding the default reset.

I assume that if I set the top level collection to null, that there is
no longer a reference to the other nested collections and they are
garbage collected.

When I re-use the actionForm within the same session, the collections
that were nested are still in session scope and reappear. But, the
collection that I set to null is null.

I am sure I am getting the correct session bean because I check for an
attribute with a unique value before and after I call my reset.

I would really appreciate any insight or suggestions.

Thanks
Al

-- 
Al Willingham [EMAIL PROTECTED]


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



RE: Removing nested bean collections in session scope.......

2003-04-03 Thread Al Willingham
If I remove the mapping to my actionForm, I get an error indicating that
my jsp cannot retrieve definition for form bean null. Do I need to
usebean scope = session??

My mappings are:

First Mapping..

 action path=/Operator/network parameter=TEST
type=com.qualcomm.wirelessdevices.controller.OperatornetworkAction
  scope=session name=operatornetworkForm validate=false 
  forward name=success path=manager.Operator.networksummary/
  forward name=cancel redirect=true path=/do/Operator/list/
/action

Second Mapping
action path=/Operator/networkdetails parameter=NETDETAIL
type=com.qualcomm.wirelessdevices.controller.OperatornetworkAction
  scope=session name=operatornetworkForm validate=false 
  forward name=success path=manager.Operator.networksummary/
  forward name=successfulmanuf path=/do/Operator/list/
  forward name=cancel redirect=true path=/do/Operator/list/
/action



Changed second mapping to.

action path=/Operator/networkdetails parameter=NETDETAIL
type=com.qualcomm.wirelessdevices.controller.OperatornetworkAction
  forward name=success path=manager.Operator.networksummary/
  forward name=successfulmanuf path=/do/Operator/list/
  forward name=cancel redirect=true path=/do/Operator/list/
/action



On Thu, 2003-04-03 at 10:24, apachep2 wrote:
 I have had this issue before. In your next action, remove mapping to the
 ActionForm in your struts-config.xml.
 
 -Original Message-
 From: Al Willingham [mailto:[EMAIL PROTECTED] 
 Sent: April 3, 2003 12:47 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Removing nested bean collections in session scope...
 
 Hi,
 
 Thanks for considering this...
 
 I'm really stumped. I have several layers of collections, ie, a nest of
 beans inside a nested bean in an actionForm with session scope. When I
 am finished with the collections, I call my own reset method and set the
 top level collection to null. I am not overriding the default reset.
 
 I assume that if I set the top level collection to null, that there is
 no longer a reference to the other nested collections and they are
 garbage collected.
 
 When I re-use the actionForm within the same session, the collections
 that were nested are still in session scope and reappear. But, the
 collection that I set to null is null.
 
 I am sure I am getting the correct session bean because I check for an
 attribute with a unique value before and after I call my reset.
 
 I would really appreciate any insight or suggestions.
 
 Thanks
 Al
-- 
Al Willingham [EMAIL PROTECTED]


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



Session bean lifecycle.......

2003-04-02 Thread Al Willingham
Hi,

Is is true that a session bean gets created when an actionMapping is
requested that has scope set to session? 

And if one with the same name already exists, it gets re-used, existing
contents and all?

If I want to reset to the default state, can I get the session bean
session.getAttributeName(mybeanname) and call reset() and expect a
default actionForm ?

Thanks for your time,
Al


-- 
Al Willingham [EMAIL PROTECTED]


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



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

2003-03-31 Thread Al Willingham
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 [EMAIL PROTECTED]


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



Re: Session bean behavior when user creates new browserwindow......

2003-03-31 Thread Al Willingham
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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Al Willingham [EMAIL PROTECTED]


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



Re: Session bean behavior when user creates new browserwindow......

2003-03-31 Thread Al Willingham
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: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Al Willingham [EMAIL PROTECTED]


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