Announcement Announcement Module
Collapse
No announcement yet.
Spring Batch Support for Non-RDBMS Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Batch Support for Non-RDBMS

    I need to convert an existing JPA Hibernate Spring Batch project to use a non-RDBMS JPA EntityManager. I am fairly new to Spring Batch and I'm trying to figure out if it's possible to do this before I start. I can convert the DAOs from JdbcTemplate to JPA EntityManager, but I don't know if it would waste my time.

    The existing spring configuration -

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans"
    	xmlns:aop="http://www.springframework.org/schema/aop"
    	xmlns:tx="http://www.springframework.org/schema/tx"
    	xmlns:p="http://www.springframework.org/schema/p"
    	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    	xsi:schemaLocation="
    		http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    		http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
    		http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">
    
    	<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
    		<property name="dataSource" ref="dataSource" />
    	</bean>
    
    	<bean id="jobLauncher" class="org.springframework.batch.core.launch.support.SimpleJobLauncher">
    		<property name="jobRepository" ref="jobRepository" />
    	</bean>
    	
    
    	<bean class="org.springframework.batch.core.configuration.support.JobRegistryBeanPostProcessor">
    		<property name="jobRegistry" ref="jobRegistry"/>
    	</bean>
    	
    	<bean id="jobRegistry" class="org.springframework.batch.core.configuration.support.MapJobRegistry" />
    	
    	<bean id="jobRepository" class="org.springframework.batch.core.repository.support.JobRepositoryFactoryBean">
    		<property name="dataSource" ref="dataSource" />
    		<property name="transactionManager" ref="transactionManager" />
    		<property name="databaseType" value="mysql" />
    	</bean>
    
    </beans>
    Looking into the most recent Spring Batch API, it appears that Datasource is the only supported type of injection to a JobRepository and SimpleJobLauncher.

    If I don't need a datasource for this, I might be able to get something working. I can create an EntityManager via the persistence.xml and avoid the Datasource (which I do not have any drivers for) instantiation.

    I am working with a DataNucleus JPA provider and an unsuppported database type (it's really a WS connection). Hopefully someone can respond, even if it is to say not possible.

    Thanks,
    Keith

  • #2
    @Keith,

    There are core components in Spring Batch ( e.g. JobRepository, JobExplorer, JobService, etc.. ) that rely on Relational Database.

    ( updated after Dave's clarification below: implementations of which currently rely only on Relational Database )

    In Spring Batch 3.0, I would expect, with the rise of NoSQL movement ( Spring Data ) there will be alternatives, but as of right now relational database is needed for Spring Batch metadata. One of the main reasons for this is to ensure clean restartability and rollbacks due to relational databases solid support for transactions.

    I remember Baruch Sadogursky rewrote Spring Batch core components to rely on NoSQL data store ( http://blog.sadogursky.com/2010/04/2...-spring-batch/ ), so if you'd like to take on a challenge, you can get more info from Baruch. After you're done, your feedback is welcome of course

    /Anatoly
    Last edited by litius; Oct 30th, 2010, 04:22 PM. Reason: Dave's correction below

    Comment


    • #3
      Just to clarify what Anatoly is saying: the JobRepository (and friends) are interfaces in Spring Batch so they do not depend on any relational database features as such. If your data is in a non-relational store there is nothing stopping you from using it with a relational store for the Batch metadata, but there will be limitations: principally, there will not be a transaction manager that can span both resources, so the transaction semantics will not be the same. Indeed if you are using a non-relational store it is unlikely that even using it for the JobRepository would have the same semantics as the existing relational implementation. In particular you lose some quality of service guarantees (e.g. preventing duplicate concurrent launches, and some of the robustness of restartability).

      Comment

      Working...
      X