Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Geronimo and JSR-237 WorkManager API for App Servers
Date: Tue, 28 Jun 2005 19:37:21 +0100
Message-ID: 
 <A115BA9D0BDB134DA4B5E0022FD614730152F550@kccxoex05.corp.kpmgconsulting.com>
Thread-Topic: Geronimo and JSR-237 WorkManager API for App Servers
Thread-Index: AcV3asEc4iZOX3uwRqSunpdBYLFXygEodgXA
From: "Tyagi, Rahul" <rahul.tyagi@bearingpoint.com>
To: <dev@geronimo.apache.org>


David,

My thoughts are inline.....

>Well, I think implementing this would be great.  I'd like to know:
>- whether  WorkManager could use our thread pool gbean or if we should =0D
>replace uses of the thread pool gbean with WorkManager or some other =0D
>relationship
>- whether the J2CA WorkManager should use the jsr-23 WorkManager or =0D
>vice versa or neither

I think we have to wrap work manager as gbean and we can/should implement=
 WorkManager without using any other gbean. WorkManager would be available=
 in JNDI tree and app may refer workmanager in its config descriptor(i.e.=
 resource-ref tag). WorkManager may internally use Doug's concurrent API,=
 Or We can start using java.util.concurrent package or backport of=
 concurrent API to jdk 1.4, We can have separate discussion to decide which=
 API we should use.

>Our transaction manager is rather aggressively single threaded, so =0D
>currently any jsr-237 implementation is going to have to not  propagate =0D
>transactions between threads.  We need to look at the advanced =0D
>transaction services spec (activity service?) to see what they have to =0D
>say about this also.  I'd be delighted to talk more about this =0D
>issue.... next week ;-)

As you know JSR-237 do not state anything about work being transaction=
 aware, To start with we can use existing transaction manager. I think we=
 need detail discussion about transaction management within Geronimo i.e.=
 distributed transaction.

Let me know your thoughts!!

Thanks,

Rahul


-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]
Sent: Wednesday, June 22, 2005 3:41 PM
To: dev@geronimo.apache.org
Subject: Re: Geronimo and JSR-237 WorkManager API for App Servers


Well, I think implementing this would be great.  I'd like to know:
- whether  WorkManager could use our thread pool gbean or if we should =0D
replace uses of the thread pool gbean with WorkManager or some other =0D
relationship
- whether the J2CA WorkManager should use the jsr-23 WorkManager or =0D
vice versa or neither

Our transaction manager is rather aggressively single threaded, so =0D
currently any jsr-237 implementation is going to have to not  propagate =0D
transactions between threads.  We need to look at the advanced =0D
transaction services spec (activity service?) to see what they have to =0D
say about this also.  I'd be delighted to talk more about this =0D
issue.... next week ;-)

thanks
david jencks

On Jun 22, 2005, at 1:27 PM, Tyagi, Rahul wrote:

>
> You can assume WorkManager to be a container managed thread pool. =0D
> Using WorkManager one can schedule work workManager.schedule(Work =0D
> work) and schedule would get a thread from container managed thread =0D
> pool and process the work (Work implements java.lang.Runnable). It has =0D
> capability to add dependency of work completion on other work. Work =0D
> has life cycle and user can define listener for listening to those =0D
> work life cycle events.
>
>>>>> David Jencks Wrote
>
>> I saw only a very early draft of this JSR, which IMO had the fatal
>> defect of not explaining the semantics of transactions when using the
>> thread pool.  Has the current version of the spec added any discussion
>> of transactions?
>
> So far this specification do not state anything for managing =0D
> transaction. But i think we need to enhance that part. I personally =0D
> believe in both approach standardize first then implement Or =0D
> Innovate/implement first and then standardize, In our case we need to =0D
> follow later :)...
>
> To avoid security message probably i would start using my personal =0D
> email ID for this email list.
>
> Thanks,
>
> Rahul
>
>
> -----Original Message-----
> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
> Sent: Wednesday, June 22, 2005 3:40 PM
> To: dev@geronimo.apache.org
> Subject: Re: Geronimo and JSR-237 WorkManager API for App Servers
>
>
> On Wed, 22 Jun 2005, Tyagi, Rahul wrote:
>> ...
>> I think JSR-237 is a major step in writing scalable parallel =0D
>> processing
>> application within managed environment.
>
> Can you give us some more detail on what JSR-237 requires from the app
> server?
>
> Also, the footer block below needs to go!  :)
>
> Thanks,
> 	Aaron
>
> ***********************************************************************=0D
> ****************************
> The information in this email is confidential and may be legally =0D
> privileged.  Access to this email by anyone other than the intended =0D
> addressee is unauthorized.  If you are not the intended recipient of =0D
> this message, any review, disclosure, copying, distribution, =0D
> retention, or any action taken or omitted to be taken in reliance on =0D
> it is prohibited and may be unlawful.  If you are not the intended =0D
> recipient, please reply to or forward a copy of this message to the =0D
> sender and delete the message, any attachments, and any copies thereof =0D
> from your system.
> ***********************************************************************=0D
> ****************************
>


***************************************************************************=
************************
The information in this email is confidential and may be legally=
 privileged.  Access to this email by anyone other than the intended=
 addressee is unauthorized.  If you are not the intended recipient of this=
 message, any review, disclosure, copying, distribution, retention, or any=
 action taken or omitted to be taken in reliance on it is prohibited and=
 may be unlawful.  If you are not the intended recipient, please reply to=
 or forward a copy of this message to the sender and delete the message,=
 any attachments, and any copies thereof from your system.
***************************************************************************=
************************