Need Hibernate configuration (hibernate.cfg.xml) file for mysql cluster.
[Hibernate] Auto Generate POJO Classes and *.hbm.xml files.
I am able to access Mysql Database using following configuration.
And i am also able to access MYSQL NDB Cluster database using simple JDBC connectivity.
Problem is when i am using MYSQL NDB Cluster database credentials that time i am not able to access Database using Hibernate.
Please suggest any other configuration for Connect MYSQL NDB CLuster database using Hibernate configuration file (hibernate.cfg.xml).
I think the soluation is new dialect is required for MySQL NDB clustered table types. Otherwise any changes in configuration file
<property name="hibernate.bytecode.use_reflection_optimizer">false</property>
<property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.connection.password">HAZE@rt!f!c!aldb</property>
<property name="hibernate.connection.pool_size">10</property>
<property name="hibernate.connection.url">jdbc:mysql://192.168.1.187:3306/haze_videocon_v0.8</property>
<property name="hibernate.connection.username">haze</property>
<property name="hibernate.current_session_context_class">thread</property>
<property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="hibernate.search.autoregister_listeners">false</property>
<property name="hibernate.show_sql">true</property>
<property name="hibernate.validator.apply_to_ddl">false</property>
</session-factory>
It is necessary to have MySQL Cluster up and running. For simplicity all of the nodes (processes) making up the Cluster will be run on the same physical host, along with the application.
These are the MySQL Cluster configuration files being used :
config.ini:
my.cnf:
This focuses on ClusterJ rather than on running MySQL Cluster; if you are new to MySQL Cluster then refer to running a simple Cluster before trying this.
ClusterJ needs to be told how to connect to our MySQL Cluster database; including the connect string (the address/port for the management node), the database to use, the user to login as and attributes for the connection such as the timeout values. If these parameters aren’t defined then ClusterJ will fail with run-time exceptions. This information represents the “configuration properties” shown in Figure 3. These parameters can be hard coded in the application code but it is more maintainable to create a clusterj.properties file that will be imported by the application. This file should be stored in the same directory as your application source code.
clusterj.properties:
As ClusterJ will not create tables automatically, the next step is to create ‘clusterdb’ database (referred to in clusterj.properties) and the ‘employee’ table:
The next step is to create the annotated interface:
Employee.java:
The name of the table is specified in the annotation @PersistenceCapable(table=”employee”) and then each column from the employee table has an associated getter and setter method defined in the interface. By default, the property name in the interface is the same as the column name in the table – the column name has been overridden for the City property by explicitly including the @Column(name=”municipality”) annotation just before the associated getter method. The @PrimaryKey annotation is used to identify the property whose associated column is the Primary Key in the table. ClusterJ is made aware of the existence of indexes in the database using the @Index annotation.
The next step is to write the application code which we step through here block by block; the first of which simply contains the import statements and then loads the contents of the clusterj.properties defined above:
Main.java (part 1):
The next step is to get a handle for a SessionFactory from the ClusterJHelper class and then use that factory to create a session (based on the properties imported from clusterj.properties file.
Main.java (part 2):
// Create a session (connection to the database) SessionFactory factory = ClusterJHelper.getSessionFactory(props); Session session = factory.getSession(); Now that we have a session, it is possible to instantiate new Employee objects and then persist them to the database. Where there are no transaction begin() or commit() statements, each operation involving the database is treated as a separate transaction.
Main.java (part 3):
/
At this point, a row will have been added to the ‘employee’ table. To verify this, a new Employee object is created and used to read the data back from the ‘employee’ table using the primary key (Id) value of 998:
Main.java (part 4):
This is the output seen at this point:
Check the database before I change the Employee - hit return when you are done The next step is to modify this data but it does not write it back to the database yet:
Main.java (part 5):
The application will pause at this point and give you chance to check the database to confirm that the original data has been added as a new row but the changes have not been written back yet:
After hitting return, the application will continue and write the changes to the table, using an automatic transaction to perform the update.
Main.java (part 6):
The application will again pause so that we can now check that the change has been written back (persisted) to the database:
The application then goes onto create and persist 100 new employees. To improve performance, a single transaction is used to that all of the changes can be written to the database at once when the commit() statement is run:
Main.java (part 7):
The 100 new employees will now have been persisted to the database. The next step is to create and execute a query that will search the database for all employees in department 777 by using a QueryBuilder and using that to build a QueryDomain that compares the ‘department’ column with a parameter. After creating the, the department parameter is set to 777 (the query could subsequently be reused with different department numbers). The application then runs the query and iterates through and displays each of employees in the result set:
Main.java (part 8):
At this point, the application will display the following and prompt the user to allow it to continue:
We can compare that output with an SQL query performed on the database:
Finally, after pressing return again, the application will remove all employees:
Main.java (part 9):
As a final check, an SQL query confirms that all of the rows have been deleted from the ‘employee’ table.