Quartz & Websphere 6

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Quartz & Websphere 6

popianovka
I would like to use Quartz with Websphere 6.0.  Does Quartz work well with Websphere 6.0?  Any comments would be appreciated.

Bill
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=21184&messageID=40939#40939

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

popianovka
We are currently using quartz with WebSphere 6 for one of our applications, though we aren't using a persistent jobstore. We've not seen any significant problems with it, although I think there was some mention of JNDI lookup aggravations at one point. You may have some problems with the EJBInvokerJob, I don't know... We wrote our own jobs, which do successfully call some SLSB methods.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=21184&messageID=40941#40941

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

popianovka
Aaron,

    Thank you very much for the quick response.  Appreciated.

        Bill
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=21184&messageID=40947#40947

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

popianovka
Glad to help. Good luck with your project.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=21184&messageID=40964#40964

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

popianovka
In reply to this post by popianovka
Hi,

Is it possible to get the required non container managed transaction connection from WAS's Data Source?

[b]org.quartz.jobStore.nonManagedTXDataSource = nonManagedTX
org.quartz.dataSource.nonManagedTX.jndiURL=jdbc/nonManagedTX[/b]

In fact, in my Stateless Session Bean, I try

[b]Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();[/b]
scheduler.addJob(job, true);

It always fails to run the first line.

Error in update. It may be due to concurrent update by another user. Please try again.
Error in update. It may be due to concurrent update by another user. Please try again.
SystemErr     R org.quartz.SchedulerConfigException: Failure occured during job recovery. [See nested exception: org.quartz.JobPersistenceException: Couldn't rollback jdbc connection. DSRA9350E: Operation Connection.rollback is not allowed during a global transaction. [See nested exception: java.sql.SQLException: DSRA9350E: Operation Connection.rollback is not allowed during a global transaction.]]
at org.quartz.impl.jdbcjobstore.JobStoreSupport.initialize(JobStoreSupport.java:493)
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=21184&messageID=54738#54738

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

twivel
I've just got a confirmation that it is NOT possible to get the non container managed DataSource from WebSphere.  They do not have a configuration option on a data source to avoid enlisting its connections in a global transaction.  What this means is that you basically have 3 options here:

1. Use global transactions, point the CMT data source to a WAS data source and encode the NonTX data source URL directly in the quartz.properties (ugly!).
2. Don't use global transactions within your application code - then just use quartz with JobStoreTX.
3. It was suggested we could modify the quartz source code to not call commit.... :)

In our application, this really sucks - we need global transactions so we must choose option 1, which means we need to embed the JDBC URL in a configuration file as well as configure it in data sources.

--
Brian

popianovka wrote
Hi,

Is it possible to get the required non container managed transaction connection from WAS's Data Source?

[b]org.quartz.jobStore.nonManagedTXDataSource = nonManagedTX
org.quartz.dataSource.nonManagedTX.jndiURL=jdbc/nonManagedTX[/b]

In fact, in my Stateless Session Bean, I try

[b]Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler();[/b]
scheduler.addJob(job, true);

It always fails to run the first line.

Error in update. It may be due to concurrent update by another user. Please try again.
Error in update. It may be due to concurrent update by another user. Please try again.
SystemErr     R org.quartz.SchedulerConfigException: Failure occured during job recovery. [See nested exception: org.quartz.JobPersistenceException: Couldn't rollback jdbc connection. DSRA9350E: Operation Connection.rollback is not allowed during a global transaction. [See nested exception: java.sql.SQLException: DSRA9350E: Operation Connection.rollback is not allowed during a global transaction.]]
at org.quartz.impl.jdbcjobstore.JobStoreSupport.initialize(JobStoreSupport.java:493)
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=21184&messageID=54738#54738

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@quartz.dev.java.net
For additional commands, e-mail: users-help@quartz.dev.java.net
Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

James House

I hope that it's well understood that #3 is far more involved than
modifying the code to "not call commit".

Using XAConnections is not just a matter of not calling commit.  It also
involves having an XA transaction in progress before the connection is
used, and properly committing (or rolling back) the transaction when
finished with the work.  This means inserting code for obtaining a
handle to a UserTransaction object from the application server, and
managing it all properly.  This isn't rocket science (and is done
elsewhere in Quartz) - but is considerably more than deleting the lines
of code that call commit on the connection.

It has long been discussed as a desire to modify JobStoreCMT such that
it only utilizes the one XADataSource, but the problem is that it then
becomes significantly more complicated to re-use the code that
JobStoreTX uses.   Not impossible, but a significant refactoring - which
would also involve modifying the JobStore interface itself.   Because of
this, the task hasn't been undertaken up to this point.

That said it was one of the first things on the list when the Quartz 2.0
road map was drafted some weeks ago ... so perhaps we'll finally do it.


james


twivel wrote:

> I've just got a confirmation that it is NOT possible to get the non container
> managed DataSource from WebSphere.  They do not have a configuration option
> on a data source to avoid enlisting its connections in a global transaction.
> What this means is that you basically have 3 options here:
>
> 1. Use global transactions, point the CMT data source to a WAS data source
> and encode the NonTX data source URL directly in the quartz.properties
> (ugly!).
> 2. Don't use global transactions within your application code - then just
> use quartz with JobStoreTX.
> 3. It was suggested we could modify the quartz source code to not call
> commit.... :)
>
> In our application, this really sucks - we need global transactions so we
> must choose option 1, which means we need to embed the JDBC URL in a
> configuration file as well as configure it in data sources.
>
> --
> Brian
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

James House
In reply to this post by twivel

Also, I just can't help myself from commenting on this:

I find it *astounding* that Websphere  *requires* you to use
XADataSources.  

Don't lots of people want to utilize non-xa-enabled databases?

And don't lots of people who do have xa-capability want to avoid the
overhead of XA if they are only using one resource?


And why does calling datasource.getConnection() start a global
transaction (as revealed by the stack trace you posted)?  That's just
stupid.   A global transaction should only be started when  a) a call
thread passes through a demarcated boundary for a container managed
transaction (e.g. when a SessionBean method is invoked) or b) when
UserTransaction.begin() is called.  

There's nothing in any Java EE specs that says
datasource.getConnection() can or should have the side effect of
starting a transaction - only that if it is an XADataSource that the
returned connection will have been enlisted with the current (already
started) transaction.


I have a hard time believing Websphere is that far out of spec.   Are
you by chance firing up (initializing) Quartz from within an EJB or
other container managed entity?!?  If so, I would guess that THAT is the
root of your problems.


james


twivel wrote:

> I've just got a confirmation that it is NOT possible to get the non container
> managed DataSource from WebSphere.  They do not have a configuration option
> on a data source to avoid enlisting its connections in a global transaction.
> What this means is that you basically have 3 options here:
>
> 1. Use global transactions, point the CMT data source to a WAS data source
> and encode the NonTX data source URL directly in the quartz.properties
> (ugly!).
> 2. Don't use global transactions within your application code - then just
> use quartz with JobStoreTX.
> 3. It was suggested we could modify the quartz source code to not call
> commit.... :)
>
> In our application, this really sucks - we need global transactions so we
> must choose option 1, which means we need to embed the JDBC URL in a
> configuration file as well as configure it in data sources.
>
> --
> Brian
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

twivel
In reply to this post by James House
Yes, that is understood, thus the smiley after the bullet item :)

--
Brian

On Fri, Feb 26, 2010 at 7:30 PM, James House <[hidden email]> wrote:

>
> I hope that it's well understood that #3 is far more involved than modifying
> the code to "not call commit".
>
> Using XAConnections is not just a matter of not calling commit.  It also
> involves having an XA transaction in progress before the connection is used,
> and properly committing (or rolling back) the transaction when finished with
> the work.  This means inserting code for obtaining a handle to a
> UserTransaction object from the application server, and managing it all
> properly.  This isn't rocket science (and is done elsewhere in Quartz) - but
> is considerably more than deleting the lines of code that call commit on the
> connection.
>
> It has long been discussed as a desire to modify JobStoreCMT such that it
> only utilizes the one XADataSource, but the problem is that it then becomes
> significantly more complicated to re-use the code that JobStoreTX uses.
> Not impossible, but a significant refactoring - which would also involve
> modifying the JobStore interface itself.   Because of this, the task hasn't
> been undertaken up to this point.
>
> That said it was one of the first things on the list when the Quartz 2.0
> road map was drafted some weeks ago ... so perhaps we'll finally do it.
>
>
> james
>
>
> twivel wrote:
>>
>> I've just got a confirmation that it is NOT possible to get the non
>> container
>> managed DataSource from WebSphere.  They do not have a configuration
>> option
>> on a data source to avoid enlisting its connections in a global
>> transaction. What this means is that you basically have 3 options here:
>>
>> 1. Use global transactions, point the CMT data source to a WAS data source
>> and encode the NonTX data source URL directly in the quartz.properties
>> (ugly!).
>> 2. Don't use global transactions within your application code - then just
>> use quartz with JobStoreTX.
>> 3. It was suggested we could modify the quartz source code to not call
>> commit.... :)
>>
>> In our application, this really sucks - we need global transactions so we
>> must choose option 1, which means we need to embed the JDBC URL in a
>> configuration file as well as configure it in data sources.
>>
>> --
>> Brian
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

twivel
In reply to this post by James House
Sorry, I just re-read what I posted and realized I didn't explain it well.
They don't force you to use XA, but if you use global transactions,
you are prevented from calling commit/rollback/etc on all datasources
(even non-XA data sources).  There is no configuration option
available to turn this off.

This means that you cannot use a WAS data source for the nonManagedTX
data source, you have to resort to configuring the JDBC URL directly
in the quartz.properties, which is not a great thing.

--
Brian



On Fri, Feb 26, 2010 at 7:42 PM, James House <[hidden email]> wrote:

>
> Also, I just can't help myself from commenting on this:
>
> I find it *astounding* that Websphere  *requires* you to use XADataSources.
>
> Don't lots of people want to utilize non-xa-enabled databases?
>
> And don't lots of people who do have xa-capability want to avoid the
> overhead of XA if they are only using one resource?
>
>
> And why does calling datasource.getConnection() start a global transaction
> (as revealed by the stack trace you posted)?  That's just stupid.   A global
> transaction should only be started when  a) a call thread passes through a
> demarcated boundary for a container managed transaction (e.g. when a
> SessionBean method is invoked) or b) when UserTransaction.begin() is called.
>
> There's nothing in any Java EE specs that says datasource.getConnection()
> can or should have the side effect of starting a transaction - only that if
> it is an XADataSource that the returned connection will have been enlisted
> with the current (already started) transaction.
>
>
> I have a hard time believing Websphere is that far out of spec.   Are you by
> chance firing up (initializing) Quartz from within an EJB or other container
> managed entity?!?  If so, I would guess that THAT is the root of your
> problems.
>
>
> james
>
>
> twivel wrote:
>>
>> I've just got a confirmation that it is NOT possible to get the non
>> container
>> managed DataSource from WebSphere.  They do not have a configuration
>> option
>> on a data source to avoid enlisting its connections in a global
>> transaction. What this means is that you basically have 3 options here:
>>
>> 1. Use global transactions, point the CMT data source to a WAS data source
>> and encode the NonTX data source URL directly in the quartz.properties
>> (ugly!).
>> 2. Don't use global transactions within your application code - then just
>> use quartz with JobStoreTX.
>> 3. It was suggested we could modify the quartz source code to not call
>> commit.... :)
>>
>> In our application, this really sucks - we need global transactions so we
>> must choose option 1, which means we need to embed the JDBC URL in a
>> configuration file as well as configure it in data sources.
>>
>> --
>> Brian
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Quartz & Websphere 6

dPedro
In my project I had the same problems as described here (and in couple of other forums). The problem was that spring context initialization was done inside global transaction. Within this transaction, You naturally can't do any "manual" commits or rollbacks.
Solution, kind of workaround, was to:
- set quartz beans to lazy-init="true"
- retrieve bean from application context when global transaction ended

This way you could even use XA data source and JobStoreTX as your job persistence.