adequate
adequate
adequate
adequate
 

JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF

The open source
grid computing
solution

 Home   About   Features   Download   Documentation   Forums 
May 29, 2017, 02:04:57 AM *
Welcome,
Please login or register.

Login with username, password and session length
Advanced search  
News: New users, please read this message. Thank you!
  Home Help Search Login Register  
Pages: [1]   Go Down

Author Topic: Transactions and Jobs Design  (Read 4906 times)

grigg_r

  • Guest
Transactions and Jobs Design
« on: April 20, 2010, 12:23:49 AM »

I can see using JTA resource manager and writing a resource adapter for evocations from execution node
Also, providing entries for task (client).

What I'm not sure what alternative would be used to implement this without JTA resource manager.


Also, would creating a job queue reader and consolidated output queue be desirable in this feature addition?


Any thoughts?
Logged

lolo

  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2172
    • JPPF Web site
Re: Transactions and Jobs Design
« Reply #1 on: April 20, 2010, 04:33:20 AM »

Hello,

Quote
I can see using JTA resource manager and writing a resource adapter for evocations from execution node
Also, providing entries for task (client).

What I'm not sure what alternative would be used to implement this without JTA resource manager.

Whether we want to integrate with a JTA transaction manager or not, we will have to design a resource manager of some sort to implement this functionality.
From a JTA transaction manager perspective, it means essentially implementing the XAResource interface for JPPF jobs/tasks, as it defines the contract between the transaction manager and resource manager.

I don't see why you mention a resource adapter at the node level. JPPF nodes, like almost everything else in JPPF, are not running in a managed environment (at least not in the J2EE sense), but rather they are standalone J2SE components. We do have a J2EE resource adapter that wraps a JPPF client in order to JPPF-enable application servers, and we should think of adding transaction support to it, but that shouldn't be the main focus, at least at the beginning.

I recommend that you read the JPPF documentation first, to familiarize yourself with the framework and understand how it works and its capabilities.

In terms on design thoughts, my preferences would be to implement this feature as a JPPF add-on (see related documentation on Extending and Customizing JPPF, and example uses and implementations in our samples pack). This would allow independent work from the rest and is well in line with the philosophy of the product. If the current extension capabilities are not sufficient, we might have to add to them to achieve our goal, which is great too.

Quote
Also, would creating a job queue reader and consolidated output queue be desirable in this feature addition?

I have no idea what you mean here. Can you please elaborate on this and on what it would bring?

Hope this helps.

Sincerely,
-Laurent
Logged
Pages: [1]   Go Up
 
JPPF Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC Get JPPF at SourceForge.net. Fast, secure and Free Open Source software downloads