[Datasource Configuration] - check-valid-connection-sql with Oracle
by Arati Chavan
Arati Chavan [http://community.jboss.org/people/AratiChavan] created the discussion
"check-valid-connection-sql with Oracle"
To view the discussion, visit: http://community.jboss.org/message/541828#541828
--------------------------------------------------------------
Hi,
We are using the JNDI for connecting to Oracle DB. Everytime Database goes down, we hae to restart Jboss to establish a new connection. I want to implement check-valid-connection-sql in the below ds file. Can someone shade some light on any potential problems or performance issues that we might encounter with this ? Below is my current ds file
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- JBoss Server Configuration -->
<!-- ==================================================================== -->
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/PassMarkDB</jndi-name>
<connection-url> jdbc:oracle:thin:@1.11.111.111:1111:rsadev</connection-url>
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
<user-name>xxxx</user-name>
<password>xxxx</password>
<min-pool-size>5</min-pool-size>
<max-pool-size>200</max-pool-size>
<metadata>
<type-mapping>Oracle10g</type-mapping>
</metadata>
</local-tx-datasource>
</datasources>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541828#541828]
Start a new discussion in Datasource Configuration at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 2 months
[EJB 3.0] - Hibernate case sensitivity problem
by Paul Dunster
Paul Dunster [http://community.jboss.org/people/Paul_Dunster] created the discussion
"Hibernate case sensitivity problem"
To view the discussion, visit: http://community.jboss.org/message/541824#541824
--------------------------------------------------------------
Hi everyone, I'm after some help please.
I have a case-sensitivity problem with Hibernate. Essentially I have no option but to support a customer that requires a case INSENSITIVE SQL DB. At the time we agreed to do this, the software ran using JBOSS 4.0.5. For many reasons we settled for a major hack to get hibernate working in an acceptable manor so that the following is permissible :-
In business logic on a stateless session bean, we may need to load (using an EntityManager) a salesorderitem entity.
The salesorderitem entity has a ManyToOne join to the ProductEntity. For this specific salesorderitem record, the productId may
be in lowercase, but on the Product record, the productId may be upper case. We may then need to get one of the properties from
the ProductEntity using the aforementioned join. In other words, case INSENSITIVE joins.
The hack was to use an AOP approach to replace the hibernate code that prevents the above scenario. I'm told that the following
classes and methods were identified as the reason we had to do this :-
org.hibernate.loader.Loader#getKeyFromResultSet - changed so that the EntityKey returned has the persisted pk Id, not the one used to load the record.
org.hibernate.util.EqualsHelper#equals - change to use equalsIgnoreCase if the two objects being compared were Strings.
Due to time constraints, commercial pressures blar blar blar, we went with this, as it worked.
Now the problem, since we went to JBOSS 4.2.3, with a newer version of the hibernate3 jar, this 'solution'
has stopped working.
Does anyone know of a better approach to solving our problem? If not, does anyone know what was changed in hibernate
that would inforce case SENSITIVE joins?
Thanks in advance, Paul.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541824#541824]
Start a new discussion in EJB 3.0 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 2 months
[JBoss Tools Development] - XModel in JBoss Tools
by Viacheslav Kabanovich
Viacheslav Kabanovich [http://community.jboss.org/people/scabanovich] modified the document:
"XModel in JBoss Tools"
To view the document, visit: http://community.jboss.org/docs/DOC-15207
--------------------------------------------------------------
Some features of JBoss Tools have XModel for their internal model. This model framework was created 8 years but remains undocumented.
It is time to fill the gap with some notes to be of use to those who might fix issues in or contribute to XModel based features.
Basics for XModel is in plugin org.jboss.tools.common.model. Basic ui components that visualize objects of XModel are in org.jboss.tools.common.model.ui.
The idea of XModel is that one can minimize Java coding by describing any model object by meta information about its structure and actions that can be done on it and bind this meta info with common implementation, which can be customised but in many cases is good by default.
That info is xml (*.meta) file registered with XModel by extension point 'org.jboss.tools.common.model.meta'.
All objects in XModel have common super interface XModelObject, and even common super class XModelObjectImpl. But of course, for the sake of
customization there are opportunities to override the default implementation.
For the start, look into *.meta files and make sure that it contains only a few basic notions. But there are some tricks that make it difficult to understand without explanations. Just several, for the beginning:
1) Entity name convention.
There are no packages and all entity names must be unique. It is solved by common prefix for a set of entities for a project. For example, all entities for Seam start with 'Seam'. With one exception: root entity of file usually starts with 'File', so root entity for components.xml starts with 'FileSeam'. That is not the requirement, but it is conveniency, which one can use within a project to filter/find entities by prefix. Version is provided by digital suffix, otherwize digits are not welcome in entity name, e.g. entities 'FileSeamComponent12', 'FileSeamComponent20' etc. are for versions 1.2, 2.0, etc. I regularly use code that assumes such suffixing to compute version (it is limited to a project, common features do not make such assumptions).
2). What is "%Regular%" in the next fragment?
<XModelEntity ImplementingClass="%Regular%" name="EclipseWorkspace">
It is quite evident that 'ImplementingClass' is a java class for XModel object that implements XModelObject (actually even always extends XModelObjectImpl). There are a few standard implementations and I decided that it would not do always to type qualified name. So, there is an idea of simple mappings with predefined names. Most of them are introduced in org.jboss.tools.common.model/resources/meta/base.meta
and contributed where needed (kind of trivial extension point, invented when there were no Eclipse around). In this case it is
<MAPPING name="Implementations">
<PAIR name="Regular"
value="org.jboss.tools.common.model.impl.RegularObjectImpl"/>
</MAPPING>
So, loader of *.meta files looks for either qualified class names or %...% expressions, and for 'ImplementingClass' attribute looks into mapping 'Implementations'.
3) What are PROPERTIES in the next fragment?
<XModelAttribute PROPERTIES="id=true;category=general"
name="component-name" xmlname="name"/>
Actually, this is the most gross trick in XModel. As I told above, there are but few basic notions in it, but one may without limitation add any set of
them by PROPERTIES attribute. Being fully aware of the danger of such approach, I introduced new property names only when quite necessary and useful.
- Property 'id' is used by implentation class org.jboss.tools.common.model.impl.CustomizedObjectImpl, usually referenced %Custom%. It marks attribute as the one which value must be unique in parent, and by default that value is used for object's path part and presentation (e.g. label in Tree)
- Property 'category' with two values 'general' and 'advanced' is used to automatically generate ui editor forms if no specific form is defined. If category=advanced, field editor for the attribute is added to Section 'Advanced', if 'category' is not set, it will not be present in ui form at all.
4) What is <XModelAttributeReference>?
<XModelEntity name="SeamJmsQueueConnection"
...
<XModelAttributeReference
attributes="class,scope,precedence,installed,auto-create"
entity="SeamComponent" name="component"/>
...
</XModelEntity>
Entities SeamComponent and SeamJmsQueueConnection have a lot in common, meta information for attributes 'class', 'scope', etc. can be inherited by the later from the former. The meta model inheritance in XModel is rather trivial, I admit it, but improving it is next to impossible because of potentially huge refactoring that it might involve (I am afraid that similar consideration will loom in the way of many a sensible suggestions for XModel improvements).
*XModel and type safety problem
*
1. In configuration meta files, one can bind entity with any implementation (extending XModelObject). XModelObject will be created with that implementation. Then, if it is necessary to work with implementing type, casting must be performed. That is not type safe operation.
2. If developer works with a large project that contains several modules, he can carelessly make use in *.meta file of one module features defined in other modules. Then, if one of these modules is not included into build for product, then build will pass but will not work.
These two and other related problems are due to lack of validation for XModel. They can be solved by adding new builder/validator for *.meta files and contribution to Java builder that would check casting types. The lack of validation is currently the greate drawback of XModel that hinders developers from using it.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15207]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
16 years, 2 months
[EJB 3.0 Development] - Possible Deadlock Jboss 4.2.3
by Daniel Cullender
Daniel Cullender [http://community.jboss.org/people/cullendw] created the discussion
"Possible Deadlock Jboss 4.2.3"
To view the discussion, visit: http://community.jboss.org/message/541800#541800
--------------------------------------------------------------
Hi,
We have been running jboss 4.2.3 for a while now. Recently we have been getting deadlocks and we are battling to narrow down the exact cause. This happens randomly and can take hours to occur. When doing a stack trace, we find the following culprits :
*Thread: WorkManager(2)-38* : priority:5, demon:true, threadId:479, threadState:BLOCKED, lockName:java.lang.Class@741b31f2
> java.lang.Class.initAnnotationsIfNecessary(Class.java:3067)
> java.lang.Class.getAnnotation(Class.java:3029)
> org.jboss.aop.annotation.AnnotationElement.getVisibleAnnotation(AnnotationElement.java:88)
> org.jboss.aop.Advisor.resolveAnnotation(Advisor.java:321)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:74)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:329)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:294)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy101.get(Unknown Source)
*Thread: AsyncNotifier-401* : priority:5, demon:false, threadId:812, threadState:BLOCKED, lockName:java.lang.Class@741b31f2
> java.lang.Class.initAnnotationsIfNecessary(Class.java:3067)
> java.lang.Class.getAnnotation(Class.java:3029)
> org.jboss.aop.annotation.AnnotationElement.getVisibleAnnotation(AnnotationElement.java:88)
> org.jboss.aop.Advisor.resolveAnnotation(Advisor.java:321)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:74)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:329)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:294)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy101.get(Unknown Source)
The method java.lang.Class.initAnnotationsIfNecessary is synchronized and it seems that both threads are hanging on the same class java.lang.Class@741b31f2.
Any ideas why this would start happening all of a sudden? We upgraded to the latest java 6 patch recently and I am curious if any changes were made to the Class class ....
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541800#541800]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 2 months
