Thursday, August 24, 2006
inverse attribute in Hibernate - What does it mean?
This is the best explanation, that i have seen till date, about Hibernate's "inverse" attribute:
Meaning of "inverse" in Hibernate
Labels:
Hibernate
Evict collection from Hibernate second level cache
Hibernate allows persistent objects to be cached in its second level cache(The first level cache in Hibernate is the Session object which is ON by default). Applications can switch on the second level cache. When a object is being retrieved by the application through Hibernate, Hibernate first checks in its Session cache and then the Second level cache to see if the object has be retrieved already. If it finds it either the Session cache or the Second level cache, it will NOT fire a query to the database.
While configuring second level cache, the object can be cached and also the collections contained in the object can be cached. Have a look at the following example:
<hibernate-mapping default-lazy="false" >
<class name="org.myapp.ho.Parent" table="Parent">
<b><cache usage="read-only" /> </b>
<id name="id" type="Integer" column="ID" />
<set name="myChildren">
<b> <cache usage="read-only"/> </b>
<one-to-many class="org.myapp.ho.Child"/>
</set>
</class>
</hibernate-mapping>
<hibernate-mapping default-lazy="false" >
<class name="org.myapp.ho.Child" table="Child">
<b><cache usage="read-only" /></b>
<id name="id" type="Integer" column="ID" />
</class>
</hibernate-mapping>
Note that we have used the cache setting at 3 places:
1) The org.myapp.ho.Parent object
2) The "myChildren" collection in the org.myapp.ho.Parent object
3) The org.myapp.ho.Child object
When you configure a collection to be second level cached in Hibernate, it internally maintains a SEPERATE cache for these collection than the one which it uses to cache the parent objects. So in the example above, the “myChildren” will be cached separately than the org.myapp.ho.Parent object.
There might be cases where applications would want to evict objects from the cache. If its the Session cache from which the application has to evict the object then the call to Session.evict will cascade even to collections and will evict the collection from the *Session cache*. However, if the object(and the collections contained in it) have to be evicted from the second level cache, then the application has to *explicitly* call the evictCollection method on the SessionFactory to remove the *collection* contained in the Parent object. The reason behind this is, as already mentioned, the collections are cached separately, than the parent objects, in the second level cache.
So, in our example above, if we have to evict the Parent with id 500 and its collection from the second level cache, then here’s what has to be done:
SessionFactory sf = MyUtil.getSessionFactory();
//this will evict the Parent Object from the second level cache
sf.evict(org.myapp.ho.Parent.class,new Integer(500));
//this will evict the collection from the second level cache for the Parent with id=500
sf.evictCollection(org.myapp.ho.Parent.class.getName() + ".myChildren", new Integer(500));
The first parameter to the evictCollection method is the ‘roleName’ of the collection. The roleName is formed as follows:
roleName = NameOfTheParentClass + "." + NameOfTheCollectionInsideTheParent
The second parameter the evictCollection method is the id of the parent object, to which this collection belongs.
Labels:
Hibernate
Custom reverse engineering strategy in Hibernate
Hibernate has tools to create mapping files(hbm files) and domain model classes from database schemas(reverse engineering).
Labels:
Hibernate
Convert exception stacktrace to String object
Usually whenever a exception occurs, we use the method printStackTrace() on the exception object to display the stacktrace. However, if the stacktrace has to be stored into a String object then the following piece of code will prove handy:
/**
* Creates and returns a {@link java.lang.String} fromt’s stacktrace
* @param t Throwable whose stack trace is required
* @return String representing the stack trace of the exception
*/
public String getStackTrace(Throwable t) {
StringWriter stringWritter = new StringWriter();
PrintWriter printWritter = new PrintWriter(stringWritter, true);
t.printStackTrace(printWritter);
printWritter.flush();
stringWritter.flush();
return stringWritter.toString();
}
Labels:
Java
Lookup an EJB from a different application, deployed on the same server, in JBoss
Question:
I have a web application through which i want to access an EJB which is deployed as a separate appliaction on the same server. How do i do it?
Answer:
In the web.xml of your war(the web application through which you want to access the EJB), have the following entry:
<ejb-ref>
<ejb-ref-name>GiveAnNameByWhichYouWouldLikeToReferTheBeanInYourWebApp</ejb-ref-name>
<ejb-ref-type>session</ejb-ref-type>
<home>packageName.ClassNameOfTheHomeObjectOfTheBeanYouWantToRefer</home>
<remote>packageName.ClassNameOfTheRemoteObjectOfTheBeanYouWantToRefer</remote>
</ejb-ref>
In the jboss-web.xml of your war, have the following entry:
<ejb-ref>
<!--The ejb-ref-name should be same as the one given in the web.xml above -->
<ejb-ref-name>GiveANameByWhichYouWouldLikeToReferTheBeanInYourWebApp</ejb-ref-name>
<!--Example:somecontext/somejndiName.YouWillFindThisJndiNameInTheJboss.xmlOfTheEJB-->
<jndi-name>TheJndiNametoWhichTheBeanIsBound</jndi-name>
</ejb-ref>
For more info, have a look at the dtds of web.xml (http://java.sun.com/dtd/web-app_2_3.dtd) and jboss-web.xml(http://www.jboss.org/j2ee/dtd)
In your code, do the lookup as:
Context ic = new InitialContext();
Object home=ic.lookup("java:comp/env/TheNameThatYouHadGivenInEjb-ref-nameTagOfJbossWeb.xml");
Here’s an example:
web.xml:
<ejb-ref>
<ejb-ref-name>MyTestBean</ejb-ref-name>
<ejb-ref-type>session</ejb-ref-type>
<home>com.test.ejb.MyBeanHome</home>
<remote>com.test.ejb.MyBeanRemote</remote>
</ejb-ref>
jboss-web.xml:
<ejb-ref>
<ejb-ref-name>MyTestBean</ejb-ref-name>
<jndi-name>myejb/test/MyTestBean</jndi-name>
</ejb-ref>
Lookup code:
Context ic = new InitialContext();
Object ejbHome = ic.lookup("java:comp/env/MyTestBean");
How to create a Queue/Topic in JBoss?
Queues/Topics are known as administered objects and in jboss they can be deployed through ServiceDotXml files. Let’s name our file, myapp-destination-service.xml. The contents of the file should look like:
<?xml version="1.0" encoding="UTF-8"?>
<server>
<!--My queue, named: myAppQueue -->
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=myAppQueue">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
</mbean>
<!-- My topic, named: myAppTopic -->
<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=myAppTopic">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
</mbean>
</server>
Place this file in your %JBOSS_HOME%/server/default/deploy directory and start the server.
(Note: If you are using the ‘all’ configuration or the ‘minimal’ configuration then you will have to place this file in the %JBOSS_HOME%/server/all/deploy or %JBOSS_HOME%/server/minimal/deploy directory, as appropriate).
The above queue/topic will be bound to the jndi name: queue/myAppQueue and topic/myAppTopic respectively.
Note:
1) The above file is meant for JBoss-3.2.3. Though there might be slight changes to later versions of JBoss, the basic configuration mechanism remains the same.
2) JBoss also comes with preconfigured queues/topics. These configurations can be found in the jbossmq-destinations-service.xml file which is present in %JBOSS_HOME%/server/default/deploy/jms directory
Update:
For JBoss AS 6.x see this FAQ for more details on how to configure JMS queue/topics
Labels:
JBoss
How to enable Garbage Collection (GC) logs
To enable GC logs, the -Xloggc:logFileName option will have to be passed when java command is being executed. Additionally if the detailed log of the GC is required, then an additional -XX:+PrintGCDetails option will have to be passed.
Example: java -Xloggc:D:/log/myLogFile.log -XX:+PrintGCDetails myProg
Labels:
Java
Subscribe to:
Posts (Atom)
