-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 14 posts ] 
Author Message
 Post subject: Performance Suggestions for Massive Inserts?
PostPosted: Fri Jan 05, 2007 6:01 pm 
Beginner
Beginner

Joined: Mon Nov 22, 2004 8:53 pm
Posts: 23
I have a use case whereby I need to insert a 10 million records into a single (wide) table at one time each month [I can't change the schema]. Hibernate is perfect for the rest of the application, so I'm hoping to use it for this as well.

But the performance that I'm seeing with Hibernate is quite a bit slower then using straight JDBC. I know Hibernate is very performant, so I'm assuming that I need to change the mapping, configuration or session management and am hoping that someone might be able to provide some hints beyond what I've tried. In terms of performance, I'm concerned with the time it takes to do the inserts and am not worried about SessionFactory configuration time because it will likely be irrelevant given the quantity of inserts I need to do.

For reference I've spent quite a bit of time with the online docs and have read most of Christian Bauer and Gavin King's new book "Java Persistence with Hibernate".


I've tried several different styles and options with Hibernate and found that using the StatelessSession and batching the inserts provides the best performance, although other methods are close behind. Here's the code:
Code:
   Configuration configuration = new Configuration().configure();
   configuration.setProperty( "hibernate.jdbc.batch_size", batchSize );
   configuration.setProperty( "hibernate.cache.use_second_level_cache", "false" );
   SessionFactory sessionFactory = configuration.buildSessionFactory();
   StatelessSession session = sessionFactory.openStatelessSession();
   
   for( int i = 0; i < batches; i++ ) {
   
      Transaction tx = session.getTransaction();
      tx.begin();
      
      for( int i = 0; i <= batchSize; i++ ) {
         Object myObject = new ...
         session.insert( myObject );
      }
      
      tx.commit();
   }
   
   session.close();
   sessionFactory.close();
   



Next fastest is to use a regular session (cache off) and batch the inserts as described in "Java Persistence with Hibernate". Here's the code:
Code:
   Configuration configuration = new Configuration().configure();
   configuration.setProperty( "hibernate.jdbc.batch_size", batchSize );
   configuration.setProperty( "hibernate.cache.use_second_level_cache", "false" );
   SessionFactory sessionFactory = configuration.buildSessionFactory();
   Session session = sessionFactory.openSession();
   
   Transaction tx = session.getTransaction();
   tx.begin();
   
   for( int i = 0; i <= totalCycles; i++ ) {
      Object myObject = new ...
      session.save( myObject );
   
      if( i % batchSize == 0 ) {
         session.flush();
         session.clear();
      }
   }
   
   tx.commit();
   
   session.close();
   sessionFactory.close();
   



Next fastest is using the regular session and threading the batches. I did expect this to be faster then the above two, but the results could be hampered by a less-than-great client box. Here's the code:
Code:
   ExecutorService executorService = Executors.newFixedThreadPool( numberOfThreads );
   Configuration configuration = new Configuration().configure();
   configuration.setProperty( "hibernate.jdbc.batch_size", batchSize );
   configuration.setProperty( "hibernate.cache.use_second_level_cache", "false" );
   SessionFactory sessionFactory = configuration.buildSessionFactory();
   
   List tasks = new ArrayList();
   
   for( int i = 0; i < batches; i++ ) {
      tasks.add( new BatchCycleCallable() );
   }
   
   executorService.invokeAll( tasks );
   sessionFactory.close();
   executorService.shutdown();
   
   
   private class BatchCycleCallable
            implements Callable {
   
     public Object call() throws Exception {
        
        Session session = sessionFactory.openSession();
        Transaction tx = session.getTransaction();
        tx.begin();
   
        for( int i = 0; i <= batchSize; i++ ) {
          Object myObject = new ...
          session.save( myObject );
        }
   
        tx.commit();
        session.close();
    
        return null;
     }
   }
   



I've also tried a few other styles, but they're all slower then those described above. I've also tried JPA versions, but have experienced even less performance.

I can't use HQL to insert the records because Hibernate only supports "INSERT ... SELECT" and none of the values that I need to insert exist in the DB already.


The XML configuration for the entity is pretty basic:
Code:
   <class name="..." table="...">
   
      <composite-id name="id" class="...">
         <key-property name="..." column="..."/>
         <key-property name="..." column="..."/>
         <key-property name="..." column="..."/>
         <key-property name="..." column="..."/>
      </composite-id>
      
      <property name="..." column="..."/>
      <property name="..." column="..."/>
      
      ....and many more, but no collections or relationships...
    
   </class>
   


Here's the hibernate.cfg.xml:
Code:
   <hibernate-configuration>
      <session-factory>
         <property name="hibernate.connection.driver_class">com.microsoft.sqlserver.jdbc.SQLServerDriver</property>
         <property name="hibernate.connection.url">...</property>
         <property name="hibernate.connection.username">...</property>
         <property name="hibernate.connection.password">...</property>
         <property name="hibernate.dialect">org.hibernate.dialect.SQLServerDialect</property>
         <property name="hibernate.c3p0.min_size">10</property>
         <property name="hibernate.c3p0.max_size">50</property>
         <property name="hibernate.c3p0.timeout">600</property>
         <property name="hibernate.c3p0.max_statements">1000</property>
         <property name="hibernate.c3p0.idle_test_period">3000</property>
         <property name="show_sql">false</property>   
         <property name="hibernate.jdbc.batch_size">50</property>
      <mapping resource="....hbm.xml"/>
      </session-factory>
   </hibernate-configuration>
   


I'm experiemented with different thread pool sizes (hibernate.c3p0.max_size) and statement cache sizes (hibernate.c3p0.max_statements), but they didn't effect the results very much within the ranges that I tried.

I'm using SQL Server 2000 on a pretty decent box. I'm using the latest version of Hibernate available: 3.2.1 on JDK 1.5.0_04 (Sun's Impl).

I know there's a ton of variables, but any assistance in how to improve Hibernate's performance would be appreciated.


As a reference, here's the jist of the JDBC code that I'm using to compare: It uses a PreparedStatement and executes the inserts in batches, in multiple threads. It gets it's connections from c3p0, which uses the identical config as with the Hibernate examples above. I've tweaked the number of threads and batchsize to get it pretty performant. Here's the code (not so pretty, but hopefully it will do for comparison sake):
Code:
   ExecutorService executorService = Executors.newFixedThreadPool( numberOfThreads );
   
   List tasks = new ArrayList();
   
   for( int i = 0; i < batches; i++ ) {
      tasks.add( new BatchCallable() );
   }
   
   executorService.invokeAll( tasks );
   executorService.shutdown();
   
   
   private class BatchCycleCallable
      implements Callable {
   
      public Object call() throws Exception {
      
         Connection connection = null;
         PreparedStatement preparedStatement;
         boolean originalAutoCommitState = false;
         
         try {
         
            connection = ...getC3P0Connection();
            
            originalAutoCommitState = connection.getAutoCommit();
            connection.setAutoCommit( false );
            
            preparedStatement = connection.prepareStatement( sql );
            
            for( int i = 0; i <= batchSize; i++ ) {
               preparedStatement.set...
               preparedStatement.set...
               preparedStatement.addBatch();
            }
            
            preparedStatement.executeBatch();
            connection.commit();
         
         } catch( Exception e ) {
            e.printStackTrace();
            if( connection != null ) {
               connection.rollback();
            }
         } finally {
            if( connection != null ) {
               connection.setAutoCommit( originalAutoCommitState );
               connection.close();
            }
         }
         
         return null;
      }
   }



Thanks in advance.
-peter


Last edited by objec on Fri Jan 05, 2007 7:31 pm, edited 4 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 05, 2007 6:21 pm 
Expert
Expert

Joined: Tue Dec 28, 2004 7:02 am
Posts: 573
Location: Toulouse, France
From what you said, I guess you already read http://blog.hibernate.org/cgi-bin/blosx ... 8/26#batch

It seems like you already did almost everything doable :-). At least, it's quite normal to have jdbc performing better than hibernate, and hibernate never pretended to be better than jdbc in any case. Batch is typically one where jdbc will always be better since it has not the overhead of object mapping and caching (totally unuseful imo when inserting 10000000 rows...).

Did you try using a StatelessSession?

_________________
Baptiste
PS : please don't forget to give credits below if you found this answer useful :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 05, 2007 7:42 pm 
Beginner
Beginner

Joined: Mon Nov 22, 2004 8:53 pm
Posts: 23
batmat wrote:
Did you try using a StatelessSession?


Yep. Unfortunately the example was cut out of my posting before I hit the submit button. I just edited it back in.

And with regards to the performance..perhaps Hibernate isn't the best way to insert this many records, but I was hoping to get closer to the JDBC times. Right now the fastest times I'm seeing with Hibernate are >6 times as long as straight JDBC.

-peter


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 05, 2007 7:47 pm 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
Use StatelessSession and a profiler, I don't think 6x compared to JDBC is normal.

(Edit: On the other hand, there is some significant overhead in object creation and possibly garbage collection, so it might be normal and impossible to optimize further. What's wrong with JDBC for this?)

_________________
JAVA PERSISTENCE WITH HIBERNATE
http://jpwh.org
Get the book, training, and consulting for your Hibernate team.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 08, 2007 8:54 pm 
Beginner
Beginner

Joined: Mon Nov 22, 2004 8:53 pm
Posts: 23
Christian,

Thanks for the tips. After a bit more tweaking (and running on a multi-proc box) I was able to get Hibernate ~3x JDBC. Does this sound right?

GC time is 15-22% of the CPU time.

The only thing still of note from the profiler is that an unusually high percentage of the CPU utilization appears to be was dedicated to org.apache.commons.logging.LogFactory.getLog(Class) called from org.hibernate.type.NullableType.log(). What's stranger is that the log() method is private and the only references to it are at lower levels then what I'm running (I'm running at 'ERROR').

And as for doing this with straight JDBC, the company that I work for has standardized all future development on Hibernate. So before I do something different, I need to make sure that I can't do what we need with Hibernate...and especially that the performance that I'm seeing isn't just an error with my configuration.

-peter


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 5:45 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
can't you see stacktrace for those calls to log() ?

it should only be called if an error occurs while getting/setting values (assuming you don't have trace enabled)

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 1:37 pm 
Beginner
Beginner

Joined: Mon Nov 22, 2004 8:53 pm
Posts: 23
max wrote:
can't you see stacktrace for those calls to log() ?

it should only be called if an error occurs while getting/setting values (assuming you don't have trace enabled)


According to the profiler that I'm using, 12% of the CPU time (which accounts for ~20% of the time I care about) is spent in:
org.apache.commons.logging.LogFactory.getLog(Class), which is called by org.hibernate.type.NullableType.log(), which is called by org.hibernate.type.NullableType.nullSafeSet(PreparedStatement, Object, int). Here's the code for that method:
Code:
   public final void nullSafeSet(PreparedStatement st, Object value, int index)
      throws HibernateException, SQLException {
         try {
            if ( value == null ) {
               if ( IS_TRACE_ENABLED ) {
                  log().trace( "binding null to parameter: " + index );
               }
   
               st.setNull( index, sqlType() );
            }
            else {
               if ( IS_TRACE_ENABLED ) {
                  log().trace( "binding '" + toString( value ) + "' to parameter: " + index );
               }
   
               set( st, value, index );
            }
         }
         catch ( RuntimeException re ) {
            log().info( "could not bind value '" + toString( value ) + "' to parameter: " + index + "; " + re.getMessage() );
            throw re;
         }
         catch ( SQLException se ) {
            log().info( "could not bind value '" + toString( value ) + "' to parameter: " + index + "; " + se.getMessage() );
            throw se;
         }
      }
   


And here's the static block wheer IS_TRACE_ENABLED is getting set:
Code:
   static {
      //cache this, because it was a significant performance cost; is
      // trace logging enabled on the type package...
      IS_TRACE_ENABLED = LogFactory.getLog( StringHelper.qualifier( Type.class.getName() ) ).isTraceEnabled();
   }
   


But I'm running at ERROR. Furthermore when I set my log level down to INFO, I don't see any errors, as might be evident given the code above.

Here's my log4j.xml at INFO:
Code:
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
   
   <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
   
      <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
         <param name="Target" value="System.out"/>
         <param name="Threshold" value="INFO"/>
         
         <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="[%c{1}] %m%n"/>
         </layout>
      </appender>
      
      <root>
         <appender-ref ref="CONSOLE"/>
      </root>
   
   </log4j:configuration>



Here's the full output I see at INFO:
Code:
   [Environment] Hibernate 3.2.1
   [Environment] hibernate.properties not found
   [Environment] Bytecode provider name : cglib
   [Environment] using JDK 1.4 java.sql.Timestamp handling
   [Configuration] configuring from resource: /hibernate.cfg.xml
   [Configuration] Configuration resource: /hibernate.cfg.xml
   [Configuration] Reading mappings from resource : .....hbm.xml
   [HbmBinder] Mapping class: ... -> ...
   [Configuration] Configured SessionFactory: null
   [C3P0ConnectionProvider] C3P0 using driver: com.microsoft.sqlserver.jdbc.SQLServerDriver at URL: jdbc:sqlserver://...
   [C3P0ConnectionProvider] Connection properties: {user=..., password=****}
   [C3P0ConnectionProvider] autocommit mode: false
   [MLog] MLog clients using log4j logging.
   [C3P0Registry] Initializing c3p0-0.9.0 [built 11-July-2005 00:43:29 -0400; debug? true; trace: 10]
   [PoolBackedDataSource] Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@1c0e45a [ connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@1db7df8 [ acquireIncrement -> 1, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, identityToken -> ..., idleConnectionTestPeriod -> 3000, initialPoolSize -> 10, maxIdleTime -> 600, maxPoolSize -> 50, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 10, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@115273a [ description -> null, driverClass -> null, factoryClassLocation -> null, identityToken -> ..., jdbcUrl -> jdbc:sqlserver://..., properties -> {user=******, password=******} ], preferredTestQuery -> null, propertyCycle -> 300, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, usesTraditionalReflectiveProxies -> false ], factoryClassLocation -> null, identityToken -> ..., numHelperThreads -> 50 ]
   [SettingsFactory] RDBMS: Microsoft SQL Server, version: 8.00.2040
   [SettingsFactory] JDBC driver: Microsoft SQL Server 2005 JDBC Driver, version: 1.1.1501.101
   [Dialect] Using dialect: org.hibernate.dialect.SQLServerDialect
   [TransactionFactoryFactory] Using default transaction strategy (direct JDBC transactions)
   [TransactionManagerLookupFactory] No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
   [SettingsFactory] Automatic flush during beforeCompletion(): disabled
   [SettingsFactory] Automatic session close at end of transaction: disabled
   [SettingsFactory] JDBC batch size: 500
   [SettingsFactory] JDBC batch updates for versioned data: disabled
   [SettingsFactory] Scrollable result sets: enabled
   [SettingsFactory] JDBC3 getGeneratedKeys(): enabled
   [SettingsFactory] Connection release mode: auto
   [SettingsFactory] Default batch fetch size: 1
   [SettingsFactory] Generate SQL with comments: disabled
   [SettingsFactory] Order SQL updates by primary key: disabled
   [SettingsFactory] Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
   [ASTQueryTranslatorFactory] Using ASTQueryTranslatorFactory
   [SettingsFactory] Query language substitutions: {}
   [SettingsFactory] JPA-QL strict compliance: disabled
   [SettingsFactory] Second-level cache: disabled
   [SettingsFactory] Query cache: disabled
   [SettingsFactory] Optimize cache for minimal puts: disabled
   [SettingsFactory] Structured second-level cache entries: disabled
   [SettingsFactory] Statistics: disabled
   [SettingsFactory] Deleted entity synthetic identifier rollback: disabled
   [SettingsFactory] Default entity-mode: pojo
   [SessionFactoryImpl] building session factory
   [SessionFactoryObjectFactory] Not binding factory to JNDI, no JNDI name configured
   ...lines to my app's category omitted...
   [SessionFactoryImpl] closing
   
   Process finished with exit code 0



Last edited by objec on Tue Jan 09, 2007 3:14 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 1:39 pm 
Regular
Regular

Joined: Wed Dec 07, 2005 4:19 pm
Posts: 53
It looks like NullableType will report several conditions as
log.info or log.trace ...

It would definitely be interesting to enable that level of logging and see what is Hibernate trying to tell you.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 3:27 pm 
Beginner
Beginner

Joined: Mon Nov 22, 2004 8:53 pm
Posts: 23
mbrunecky wrote:
It looks like NullableType will report several conditions as log.info or log.trace ...

It would definitely be interesting to enable that level of logging and see what is Hibernate trying to tell you.


I don't think the output at the trace level is interesting in this case. RuntimeException's and SQLException's certainly would...but I'm not seeing any lines written that match these conditions.

The output above is running at INFO. I edited the post to make this point clear.

Is there any reason that I wouldn't see what Hibernate is writing at INFO, given that I've run at INFO? ....this certainly would help to explain why it appears there's calls to log().


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 3:56 pm 
Regular
Regular

Joined: Wed Dec 07, 2005 4:19 pm
Posts: 53
I am afraid you have to explicitly enable log levels for Hibernate package(s), the default is probably ERROR.

I am using the log4j.properties, and to 'see' Hibernate logs, I must explicitly add:

log4j.logger.org.hibernate=debug

(you may be also selective about individual Hibenate components, such as log4j.logger.org.hibernate.SQL=trace)

I do not see anything similar in your setup.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 4:10 pm 
Regular
Regular

Joined: Wed Dec 07, 2005 4:19 pm
Posts: 53
But since there are only two possible lines generating the log, they both may indicate some minor problem in your mapping file...

On the other hand, even when you trim your 20% down to 0, you would still be slow (according to your numbers).

IF the performance is such a big issue there, perhaps using a direct JDBC in an auto-commit mode is a solution (along with dropping indexes for the entire load). Even when shutting down caches etc., there is still a fair amount of Session overhead (very usefull when you are using Hibernate as what it is - object persistency management framework).

Also, there is transaction overhead when using Hibernate, that you can avoid by JDBC auto-commit=true;

Loading 1,000,000 records into database is what the (database vendor) loader utility does best - hard to compete with those :-).


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 4:15 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
as i said, figure out *when* it's called and what is the stacktrace.

it must be called at some point and either it is called waay too often and you are ignoring the errors or it is just the initialization of the logger that takes time......

put a breakpoint and debug it if anything else fails

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 7:19 pm 
Beginner
Beginner

Joined: Mon Nov 22, 2004 8:53 pm
Posts: 23
Wow, the logging config was definitely the cause of the poor performance I was seeing.

Here the detail: With this original log4j.xml:
Code:
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
   
   <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
   
      <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
         <param name="Target" value="System.out"/>
         <param name="Threshold" value="INFO"/>
         
         <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="[%c{1}] %m%n"/>
         </layout>
      </appender>
      
      <root>
         <appender-ref ref="CONSOLE"/>
      </root>
   
   </log4j:configuration>



Even though the appender is set to INFO, the following code sets IS_TRACE_ENABLED to TRUE:
Code:
   static {
      //cache this, because it was a significant performance cost; is
      // trace logging enabled on the type package...
      IS_TRACE_ENABLED = LogFactory.getLog( StringHelper.qualifier( Type.class.getName() ) ).isTraceEnabled();
   }




But if I manually set the "org.hibernate.type" category to INFO, IS_TRACE_ENABLED is set to FALSE. Here's the updated log4j.xml:
Code:
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
   
   <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
   
      <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
         <param name="Target" value="System.out"/>
         <param name="Threshold" value="INFO"/>
         
         <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="[%c{1}] %m%n"/>
         </layout>
      </appender>
      
      <category name="org.hibernate.type">
         <priority value="INFO"/>
      </category>
      
      <root>
         <appender-ref ref="CONSOLE"/>
      </root>
   
   </log4j:configuration>




And since IS_TRACE_ENABLED (in org.hibernate.type.NullableType) is now set to FALSE, Hibernate does not do the logger lookup each time.

With this change, I'm able to get Hibernate to perform nearly as fast (within a few percentage points in my tests) as JDBC! Thanks everyone for their tips.

Reflecting a bit.... I don't think that this requirement to manually set the category level to INFO is specific to my case...and it feels a little too easy to get Hibernate to perform badly in this case (taking nearly 3 times as long). I also don't know if most users are willing to (or should have too) run Hibernate through a profiler (that provides nice stack traces with line numbers, unlike mine) or use breakpoints in the Hibernate source to detect configuration/performance stipulations outside of their code.

I wonder if it might be a good idea to cache instances of the Logger, which was ultimately what was taking so long. Or maybe altering how IS_TRACE_ENABLED is set might help. It also might be good to comment on this issue on the performance faq and in the online docs...just some thoughts.

-peter


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 09, 2007 7:24 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
interesting.....please report in jira with enough files for us to reproduce.

_________________
Max
Don't forget to rate


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 14 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.