Generating Objects with users accessing objects on Web server

When generating objects do we need to lock out users from the web server so that users do not access the objects while thgey are being generated. Most we can get from people so far is that it SHOULD be ok, but have heard that if a user accesses a object as it is being generated it may corrupt it. We have done testing and it does seem to be ok, but can any one confirm this for us.

I cant really confirm it, but heres what i would expect.....

Users will be (mostly)accessing objects from the cache on the webserver (JAS). whereas your webgen will be inserting the newly generated objects directly into the serialized objects tables in the database. So your new objects will only affect users once the cache on the JAS server has cleared.
Even if the objects werent cached on the webserver (JAS), the database will be able to handle a user attempting to access a serialized object as it is being generated.

So doing webgens whilst users are active will be ok.

I hope i am correct, because if we cant do webgens whilst users are active, it is going to make working with 8.11 very difficult.
hope that helps.

We've had that same question and although it does not appear that the
users have corrupted any objects I believe there is still a risk. Chances
are that if a user is accessing an object in the persistent objects
tables, they will lock it only long enough to load it into Cache and then
release the lock. I highly doubt that this lock would last long enough
for the eGen to time out on the record so like I said - the chance of
corruption should be minimal. Just be sure to clear your caches after
your eGen is done so that the users get the updated specs.

What we have done to be SURE there is no chance of corruption is use our
Save Location as an alternate space for the eGen. We have a save location
that we use for development which is essentially a complete spare set of
specs which includes persistent objects tables. (See "Creating a Save
Location" document on KG)

During Production: The users are logging in to JPD and the OCM's are
pointing F989998 and F989999 to COPD9

- When we want to eGen we point the eGen machine's JDBj.INI file to COSV9,
- eGen JPD9 into COSV9
- When the eGen is done we have a set of OCM mappings for PD9 and JPD9
that point to COSV9 that are inactive.
- We Activate the four COSV9 OCM entries, Deactivate the four COPD9 OCM
entries for the persistent objects tables
- Clear the JDBJ Caches in SAW and voila! The users are all now pointing
to the new tables and there was NO web down time.

We don't care if the fat clients refresh their OCM's because they don't
look at the F989998 and F989999 tables anyway. So why change those
OCM's? Just in the interest of completeness and if you, as a CNC, ever
use UTB to have a look into them you want to be sure you are looking at
the right tables.

The next time we eGen we use COPD9 and reverse the whole process
effectively flip-flopping between the two sets of persistent objects. Just
check your OCM and JDBj.INI before each eGen to be sure you use the right
set.

Regards,
Gerald.






tiefenbs <[email protected]>
Sent by: [email protected]
07/18/2005 11:53 PM
Please respond to
JD Edwards=AE EnterpriseOne


To
[email protected]
cc

Subject
Generating Objects with users accessing objects on Web server






When generating objects do we need to lock out users from the web server
so that users do not access the objects while thgey are being generated.
Most we can get from people so far is that it SHOULD be ok, but have heard
that if a user accesses a object as it is being generated it may corrupt
it. We have done testing and it does seem to be ok, but can any one
confirm this for us.
EP One 8.10, Tools Release: 8.93.N1 Fat Client, Citrix XE and Portal.
Windows Server 2003, SQL 2000, Create Print, Olapworks

Let's suppose No corruption occurs (although I personally think it is possible). What happens if a user is signed on and working with one particular app. You start the gen, which will employ changes to that users app. Your generation ends successfully. The user didn't know that the generation was to occur and remains logged on. Eventually that user's app will get purged from cache and the new 'flavor' moved in. All of a sudden the user notices that the app is behaving differently and processing results that he did not expect. To the user it is a system error. This will generate panic, help desk calls, and unneccessary effort for many folks.

So barring the technology reasons as to why generations should be done with users logged off, it just makes good business practice to do these types of activities when users aren't on the system.

If you are one of those folks that refuses to work off hours, use a secondary database to generate to. Then at lunch time kick off all the users for 10 minutes to change your pointers to that new serialized DB.

I don't profess any great technical knowledge of the web server. However in our case, I regenerate objects without getting users off the web version of JDE. The specs that are generated are deployed to the generation machine and then I regenerate them. We have not had any problem. However to get the regenerated changes active I do need to get everyone off the web and bounce websphere.

Ditto... we do the GEN to an alternate set and then set the alternates to active for *PUBLIC. The ony thing we do different is to stop and start the instances in WebSphere, rather than flushing the caches. Basically, with that, the GEN can be done at any time, even with the users on the system.

[ QUOTE ]
We've had that same question and although it does not appear that the<br>users have corrupted any objects I believe there is still a risk. Chances <br>are that if a user is accessing an object in the persistent objects<br>tables, they will lock it only long enough to load it into Cache and then<br>release the lock. I highly doubt that this lock would last long enough<br>for the eGen to time out on the record so like I said - the chance of<br>corruption should be minimal. Just be sure to clear your caches after<br>your eGen is done so that the users get the updated specs.<br><br>What we have done to be SURE there is no chance of corruption is use our<br>Save Location as an alternate space for the eGen. We have a save location <br>that we use for development which is essentially a complete spare set of<br>specs which includes persistent objects tables. (See "Creating a Save<br>Location" document on KG)<br><br>During Production: The users are logging in to JPD and the OCM's are<br>pointing F989998 and F989999 to COPD9<br><br>- When we want to eGen we point the eGen machine's JDBj.INI file to COSV9,<br>- eGen JPD9 into COSV9<br>- When the eGen is done we have a set of OCM mappings for PD9 and JPD9<br>that point to COSV9 that are inactive.<br>- We Activate the four COSV9 OCM entries, Deactivate the four COPD9 OCM<br>entries for the persistent objects tables<br>- Clear the JDBJ Caches in SAW and voila! The users are all now pointing<br>to the new tables and there was NO web down time.<br><br>We don't care if the fat clients refresh their OCM's because they don't<br>look at the F989998 and F989999 tables anyway. So why change those<br>OCM's? Just in the interest of completeness and if you, as a CNC, ever<br>use UTB to have a look into them you want to be sure you are looking at<br>the right tables.<br><br>The next time we eGen we use COPD9 and reverse the whole process<br>effectively flip-flopping between the two sets of persistent objects. Just <br>check your OCM and JDBj.INI before each eGen to be sure you use the right<br>set.<br><br>Regards,<br>Gerald.<br><br><br><br><br><br><br>tiefenbs <[email protected]><br>Sent by: [email protected]<br>07/18/2005 11:53 PM<br>Please respond to<br>JD Edwards=AE EnterpriseOne<br><br><br>To<br>[email protected]<br>cc<br><br>Subject<br>Generating Objects with users accessing objects on Web server<br><br><br><br><br><br><br>When generating objects do we need to lock out users from the web server<br>so that users do not access the objects while thgey are being generated.<br>Most we can get from people so far is that it SHOULD be ok, but have heard <br>that if a user accesses a object as it is being generated it may corrupt<br>it. We have done testing and it does seem to be ok, but can any one<br>confirm this for us.<br>EP One 8.10, Tools Release: 8.93.N1 Fat Client, Citrix XE and Portal.<br>Windows Server 2003, SQL 2000, Create Print, Olapworks<br><br>

[/ QUOTE ]