Re: Sybase vs Oracle - which is better?

carl christianson wrote:
>
> I would tend to disagree that row level locking is only for "badly written"
> applications.
> An example from a previous job would be a Point of Sale system.
> In one department of this application would be preparing and shipping out
> equipment.
> Every morning new work would get loaded into the system by a batch process.
> Workers would then work this data to get it shipped out the door. Since the data
> is loaded in by
> a batch process it is put into the same data blocks. Since we had a 4K block size
> and the average
> row length is around 200 bytes we would have around 200 rows inside one block.
> I'm not sure how small your page locks could go but if I locked 200 different
> orders, remembering that since the data is all residing pretty much together I
> just put a major choke hold on the work flow for this process.
> Once this equipment is shipped out the help desk would tend to get more calls on
> the new clients and newly shipped pieces of equipment. Once again this data is
> pretty much grouped together in the database. If each helpdesk rep locked a
> couple of hundred rows when they are updating a client's information that would
> mean that other help desk reps would have to wait until they can do the same.
>
> So I guess I'm wondering how Sybase would deal with this problem and how small can
> a page lock be?
>
> regards
>
> Carl Christianson
>
> kennedyleigh_at_yahoo.com wrote:
>
> > The main reason Oracle does so well is that many Packages (eg: SAP,
> > Peoplesoft) are badly written cobol apps which use cursors for everything.
> > Sybase had a religous was with SAP over row level locking and oracle got very
> > rich because of it.
> >
> > Cheers,
> > LK.
> >
> > -----------== Posted via Deja News, The Discussion Network ==----------
> > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

With this sort of OLTP system, I would probably design the applications using an optimistic locking model. Exclusive (write) and shared (read) locks should then occur very briefly while executing queries, so the fact that they are page level locks is not terribly relevent. The point is that no processing gets locked up, or cursors left open, awaiting user action, although you do have to write code to cope with collisions (when you attempt to update/delete a row that has changed since you last read it.) Most OLTP systems I have encountered that were written for Sybase, rather than a generic RDBMS, use optimistic locking.

Row-level locking is not an issue for many long-term Sybase users because they have not designed applications that require it.

Regards,
Paul. Received on Tue Dec 01 1998 - 00:00:00 CST