Actually, the locking behavior you suggest will only be the case so long as the select is in hash order and not a SSELECT. A SSELECT will cause different batch processes to access the same groups simultaneously almost immediately, with a probability related to the number of groups (assuming well sized) and the number of batch processes.
Also don't forget that batch inputs will be processed better if you make the files read only and do not delete anything until a cleanup at the end (of all processing). Knowing that there is no problem with read/update locking, J4 files will not take the locks (unless someone changed this in jBASE 5 for instance). Also, you should look in to FASTSCAN as application programmers. Jim > -----Original Message----- > From: jbase@googlegroups.com [mailto:jbase@googlegroups.com] On Behalf > Of John Watson > Sent: Wednesday, August 17, 2011 2:59 AM > To: jBASE > Subject: Re: jbase problems show-items-locks > > Hi Pawel, > > You have said > > 'In our case high 'lock collision' ratio on group locks is killing > performance. JOB.LIST.x files suffer from multiple, concurrent 'SELECTs > SAMPLE' (~ full scan) and multiple, concurrent READUs/WRITEs' > > I'm not sure what release you use at the moment but I would only expect > to see the above problem towards the end of a job when a high number of > agents are being used - at the start of the job a list is created and > each agent takes 1/number of agents * total number of records as the > agent work load - there should be no duplication of records across > agents at this initial stage (but of course there could be a > duplication of groups) > > When this workload is consumed a full select will take place on the > JOB.LIST file and hence we can have more issues with collisions on > groups, records processed by other agents etc. > > Are you sure that the problem is actually with the JOB.LIST table and > not locks on BATCH.STATUS or BATCH - there have been problems in this > area in much older releases and they should now be addressed. > > If the issue is with group locks on the JOB.LIST file and the overhead > really is substantial then perhaps there is a logical argument to > oversize the file to minimise the number of records in a group - to be > worthwhile the increase in select time would have to outweigh the time > lost to group locks. > > Cheers, > > John. > > -- > Please read the posting guidelines at: > http://groups.google.com/group/jBASE/web/Posting%20Guidelines > > IMPORTANT: Type T24: at the start of the subject line for questions > specific to Globus/T24 > > To post, send email to jBASE@googlegroups.com To unsubscribe, send > email to jbase-unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/jBASE?hl=en -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to jBASE@googlegroups.com To unsubscribe, send email to jbase-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
