• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: FrontBase and EOF locking
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FrontBase and EOF locking


  • Subject: Re: FrontBase and EOF locking
  • From: Chuck Hill <email@hidden>
  • Date: Fri, 6 Oct 2006 15:04:20 -0700


On Oct 6, 2006, at 2:08 PM, John Huss wrote:

I was reading the documentation for FrontBase regarding locking and
was curious about this sentence:

"If the server implements the locking, the locking in the EOF is redundant, and
snapshots etc. may be turned off." (FrontBase user's guide, page 68)


Is this true?  Is it safe?  How would I turn off the locking, and is
there a performance benefit for doing it?

Here is the full quote that you are referring to (for the record):

4.2.6 Locking and Enterprise Objects Framework
Apple’s Enterprise Objects Framework (EOF) is using OPTIMISTIC locking; a transaction is started by,
for example, a fetch and is terminated when changes are saved.

Note that this is a conceptual user transaction. This is not referring to an EOF or database transaction.



EOF only checks the objects that are going
to be updated. This is not entirely correct; all objects that have been accessed should be checked.

While technically true, many objects may have been fetched in several fetches over a period of time. Only some of them are relevant to the change the user is committing.



The user
loads a number of rows, does some calculations and stores the result in a row. All the rows used for the
calculation may be changed, which is undetected, and the result would be wrong.

Assuming consistent logic, the transaction that changed one of the rows should also have updated the calculations stored in the row being updated. Thus, they will not match the snapshot in EOF and an EOF optimistic locking exception will be generated.



FrontBase does implement OPTIMISTIC locking. The limited check problem with EOF (outlined above)
can be solved by allowing nested transactions on the client; start a transaction when the user selects
objects and commit it when the user saves the changes. Actual ROLLBACK and COMMIT should be
made available to the user.

I have _no_ idea how that could be done in EOF. EOF is single threaded so this seems to require one EOF stack per user. That can eat up memory. Fast.



If the server implements the locking, the locking in the EOF is redundant, and
snapshots etc. may be turned off.

I don't recall anyway to turn snapshots off. This seems more like a theoretical discussion than something that is actually practical to implement.



Chuck

--

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects





_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >FrontBase and EOF locking (From: "John Huss" <email@hidden>)

  • Prev by Date: Direct to web question
  • Next by Date: Re: Problem generating pdf using apache FOP - PLEASE REPLY
  • Previous by thread: FrontBase and EOF locking
  • Next by thread: Direct to web question
  • Index(es):
    • Date
    • Thread