don't make decisions based on anecdotal evidence
ms
On Jul 13, 2012, at 9:03 AM, Karl <kgret...@mac.com> wrote:
> Hi,
>
> Making EOF multi-threaded is really not that desirable nor is it necessary.
> EOF gets most of its speed and efficiency through its 'cut through'
> single-threaded design at the Access layer.
>
> About 4 years ago, Apple tested an internal build of WO/EOF that was fully
> multi-threaded. It was about half as fast as the EOF that we know (and
> love?). Since then, Apple's internal version of EOF retains virtually the
> current implementation except for the snapshot layer which is now shared by
> multiple DB stacks. So the solution was to remove the 1-1 relationship
> between DB stacks and snapshots and to retain the cut-through single-threaded
> design of EOF.
>
> Karl
>
> On 2012-07-13, at 3:06 PM, Farrukh Ijaz <farrukh.i...@fuegodigitalmedia.com>
> wrote:
>
>> Sorry for late response, just landed last night.
>>
>> The idea is very simple to understand and implement. E.g. I've a third party
>> library which has a method named with following signature:
>>
>> String encode(String someString) {
>> // some crappy encoding performed on someString and saved as encoded...
>> return encoded;
>> }
>>
>> Now this method can be private, public, protected, static, final, blah blah
>> etc. I find that encoding is buggy, how to fix it? There are two ways:
>>
>> 1. Get the source code, fix the method and submit patch. (This is sometimes
>> not possible and for sure not possible in case of WebObjects)
>> 2. Use AOP
>>
>> Forget about option 1. In Option 2 we have to use some AOP mechanism and the
>> one that I've tested with my Wonder apps is AspectJ. I'm not going into
>> details as it's a vast subject but providing links which are sufficient to
>> experiment :)
>>
>> http://www.eclipse.org/aspectj/
>> http://www.eclipse.org/aspectj/doc/released/progguide/starting-aspectj.html#the-dynamic-join-point-model
>>
>> As far as weaving is concerned, I would suggest to use dynamic join point as
>> they can be used to intercept calls and invoke different code rather than
>> modifying the original classes.
>>
>> The idea is we need to define join point for the method which is buggy or
>> where we want to provide our own implementation. When the code is executed,
>> the class loader reroutes the request for incoming method calls to our code.
>> AOP is different that OOP. In contrast with OOP where methods are associated
>> with Objects, AOP is used to classify those methods under common aspects and
>> normally we use regular expressions for that. Two very common aspects I can
>> explain here:
>>
>> 1. You may have lots of methods and you want to collect execution type for
>> each method call. (A logging aspect)
>> 2. A developer like me who put all the code in try block and catch one super
>> Exception, someone would like to perform different operations on each
>> sub-exception can write an aspect to catch my exceptions and do whatever he
>> wants and then continue the original processing.
>>
>> I'm not familiar with internals of the WebObjects but the code that's
>> responsible for single thread can be studied and multithreaded solution can
>> be provided using AOP. If someone is interested to work with me to on this,
>> I'm more than happy to help where I can :)
>>
>> Farrukh
>>
>> On 2012-07-11, at 10:25 PM, Chuck Hill <ch...@global-village.net> wrote:
>>
>>> Hi Farrukh,
>>>
>>> I like the idea of using AOP to address bugs in WO. Can you give us any
>>> details on how you did that?
>>>
>>> As for making EOF multi-threaded.... that is a very fundamental part of the
>>> design. Fixing that with AOP would be challenging. :-)
>>>
>>>
>>> Chuck
>>>
>>>
>>>
>>> On 2012-07-11, at 11:12 AM, Farrukh Ijaz wrote:
>>>
>>>> Hi,
>>>>
>>>> In past I've used AOP to address issues of closed source. This I believe
>>>> if carefully used can help convert the EOF from single to multi threaded
>>>> and/or solve other bottleneck problems. Having said this doesn't mean I'm
>>>> against Cayane. However if the current EOF issues get fixed with AOP
>>>> patched code would be better for those who don't want to or for some
>>>> reasons can't switch to Cayane.
>>>>
>>>> Farrukh
>>>>
>>>> Chuck Hill <ch...@global-village.net> wrote:
>>>>
>>>>> I agree that we need to more closely examine Cayenne before jumping in
>>>>> with both feet. How mature are the tools? What is the functionality
>>>>> gap? How important is the missing functionality? How costly is adding
>>>>> any needed functionality? Will the missing functionality fit in with the
>>>>> Cayenne architecture? How stable is it? How well does it scale (scaling
>>>>> is more than multi-threaded EOF)? And Cayenne is only
>>>>> EOAccess/EOControl. What do we do about the presentation layer? Getting
>>>>> rid of 2/3 of WO still leaves you with WO.
>>>>>
>>>>>
>>>>> Chuck
>>>>>
>>>>> On 2012-07-11, at 11:29 AM, Theodore Petrosky wrote:
>>>>>
>>>>>>
>>>>>> Hurray someone actually started talking about this.
>>>>>>
>>>>>>
>>>>>> I want to add my two cents without starting a "this is better than that"
>>>>>> conversation.
>>>>>>
>>>>>> If Cayenne is to be utilized, someone in the know must look not only at
>>>>>> the current state of Cayenne, but at the developers. What is/was their
>>>>>> philosophy behind what they write/wrote? If we don't, it will be a very
>>>>>> short and costly marriage. Costly, because we either buck up and foot
>>>>>> the bill to rewrite Webobjects or continue in a bad relationship.
>>>>>>
>>>>>> I am writing this not as a diatribe but because I am concerned that in
>>>>>> the excitement of looking at Cayenne, the obvious impact of differing
>>>>>> philosophies of the original authors may be ignored. BTW, I say original
>>>>>> authors because the person that wrote the first line of code left
>>>>>> his/her imprint on the direction of all code that follows.
>>>>>>
>>>>>> JMHO (i mean that sincerely).
>>>>>>
>>>>>> Ted
>>>>>>
>>>>>>> Message: 4
>>>>>>> Date: Wed, 11 Jul 2012 10:09:08 -0500
>>>>>>> From: John Huss <johnth...@gmail.com>
>>>>>>> To: WebObjects-Dev Mailing List List <webobjects-dev@lists.apple.com>
>>>>>>> Subject: Migrating from EOF to Cayenne
>>>>>>> Message-ID:
>>>>>>>
>>>>>>> <CAOUwSGtOwEayxK4im97HucAUANo=cfnrkq9ej5z+679bcd7...@mail.gmail.com>
>>>>>>> Content-Type: text/plain; charset="windows-1252"
>>>>>>>
>>>>>>> At WOWODC there was a lot of interest in migrating from EOF
>>>>>>> to Cayenne, and
>>>>>>> even entirely rebasing Wonder to run on top of Cayenne
>>>>>>> instead of EOF.
>>>>>>>
>>>>>>> *Why would anyone want to do this? *
>>>>>>>
>>>>>>> 1. Cayenne is open-source and is actively
>>>>>>> being developed
>>>>>>> 2. Cayenne has great concurrency support
>>>>>>> which is in stark contrast to
>>>>>>> EOF single-threaded architecture
>>>>>>> 3. Cayenne is conceptually very similar to
>>>>>>> EOF so the transition is
>>>>>>> fairly straightforward
>>>>>>>
>>>>>>> For those reasons it is a much better long term solution
>>>>>>> than EOF, which is
>>>>>>> now frozen in time. Cayenne can be used inside a WO
>>>>>>> application as an EOF
>>>>>>> replacement while continuing to use the rest of WebObjects.
>>>>>>>
>>>>>>> *I'm interested. Now what?*
>>>>>>>
>>>>>>> - Learn about Cayenne. The best source of
>>>>>>> information for comparing EOF
>>>>>>> and Cayenne is on the
>>>>>>> wiki<http://wiki.wocommunity.org/display/WO/Alternative+Technologies-Cayenne>.
>>>>>>> In addition, you can look at the
>>>>>>> documentation<http://cayenne.apache.org/>for
>>>>>>> Cayenne.
>>>>>>> - Use Cayenne in your new projects.
>>>>>>> Cayenne runs just fine inside a
>>>>>>> WebObjects application. Wonder has
>>>>>>> the ERCayenne framework and
>>>>>>> ERCayenneExample to help you get started.
>>>>>>> I suggest working with the trunk
>>>>>>> of the Cayenne source (and Wonder too)
>>>>>>> since some things are just being
>>>>>>> added to make this easier.
>>>>>>> - Help work on easing and automating the
>>>>>>> migration from EOF to Cayenne.
>>>>>>> It is possible to automate a large part of
>>>>>>> the work involved in moving from
>>>>>>> EOF to Cayenne. But it requires effort.
>>>>>>> ERCayenne in Wonder has a class
>>>>>>> that will convert an EOModel to a Cayenne
>>>>>>> model (the class is
>>>>>>> CayenneConverter). This works well, but
>>>>>>> could be improved. I've started
>>>>>>> working on an Eclipse refactoring script
>>>>>>> that will convert from one API to
>>>>>>> the other. Yes, you may not have known (I
>>>>>>> didn't) that Eclipse can record a
>>>>>>> series of refactorings and save it as a
>>>>>>> script. The bulk of the migration
>>>>>>> work is creating refactoring scripts in
>>>>>>> Eclipse by performing refactorings
>>>>>>> on a stubbed out version of the EOF API to
>>>>>>> convert the API into the
>>>>>>> equivalent Cayenne API. After performing
>>>>>>> the refactorings, a script can be
>>>>>>> exported using Refactor->"Create
>>>>>>> Script". For EOF methods that do not have
>>>>>>> a direct Cayenne equivalent, helper
>>>>>>> methods (or classes) will need to be
>>>>>>> written that can serve as a direct
>>>>>>> replacement.
>>>>>>>
>>>>>>> *How can I help specifically with the migration effort?*
>>>>>>>
>>>>>>> - CayenneConverter in ERCayenne (for
>>>>>>> converting the model) does not
>>>>>>> convert the connection dictionaries in the
>>>>>>> EOModel yet.
>>>>>>> - CayenneConverter does a poor job
>>>>>>> converting fetch specs defined in the
>>>>>>> model currently.
>>>>>>> - We need to create new subclasses of
>>>>>>> Cayenne's DbAdapter that use the
>>>>>>> Wonder naming convention for primary key
>>>>>>> generators/sequences. This is done
>>>>>>> by subclassing classes like
>>>>>>> PostgresPkGenerator and overriding
>>>>>>> sequenceName. This is necessary to
>>>>>>> support existing databases created with
>>>>>>> EOF.
>>>>>>> - An Wonder-like entity template is
>>>>>>> already in ERCayenneExample. This
>>>>>>> needs to be examined and any missing
>>>>>>> functions from WonderEntity need to be
>>>>>>> added. For example, I know some the
>>>>>>> .deleteAllXXXXRelationships and
>>>>>>> .createXXXX(…) methods are missing.
>>>>>>> - More refactorings need to created. For
>>>>>>> example, a refactoring script
>>>>>>> should be made that changes NSArray and
>>>>>>> NSDictionary methods to the
>>>>>>> equivalent List or Map APIs (since Cayenne
>>>>>>> doesn't use these classes for
>>>>>>> relationships or fetch results you
>>>>>>> probably want to minimize the places you
>>>>>>> need them).
>>>>>>> - Submit code to Cayenne or create
>>>>>>> Jira<https://issues.apache.org/jira/browse/CAY>issues
>>>>>>>
>>>>>>> Any questions? :-)
>>>>>>>
>>>>>>> John
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>>>>
>>>>>> This email sent to ch...@global-village.net
>>>>>
>>>>> --
>>>>> Chuck Hill Senior Consultant / VP Development
>>>>>
>>>>> 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/gvc/practical_webobjects
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> https://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com
>>>>>
>>>>> This email sent to farrukh.i...@fuegodigitalmedia.com
>>>
>>> --
>>> Chuck Hill Senior Consultant / VP Development
>>>
>>> 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/gvc/practical_webobjects
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/kgretton%40mac.com
>>
>> This email sent to kgret...@mac.com
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com
>
> This email sent to msch...@pobox.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
