[EJB 3.0] - Dealing with not normalized data
by fhh
I have quite often come upon tables likes this:
|
| supplier articlenr size stock
| ------------------------------------------
| SuppA 100 1 57
| SuppA 100 2 63
| SuppA 100 3 19
| SuppB 100 1 12
| SuppB 100 2 21
| SuppB 100 3 51
|
|
So supplier and article number is the composite key of the table.
I want to map it to an entity that looks something like this:
|
| public class ArticleSupply {
|
| private ArticleSupplyID id;
| private Collection<SupplyInfo> supply;
|
| // ArticleSupplyID holds supplier and articlenr
| @Id @Embedded
| public ArticleSupplyID getId() {
| return id;
| }
|
| //This has size and stock information
| @OneToMany
| public Collection<SupplyInfo> getSupply() {
| return supply;
| }
|
| }
|
(I know the code above is not correct but I hope it gives you the idea.)
Obviously this is not possible since the datamodel is not normalized. This raises two problems:
1.) The ArticleSupplyID is not unique in the table.
2.) Both ArticleSupply and SupplyInfo are mapped to the same table.
One way to deal with the situation is by creating a view for ArticleSupply which looks something like this: SELECT DISTINCT supplier, articlenr FROM mytable. Then you could use a composite key for SupplyInfo to get the collection from the original table.
This should work (untested) but it is not a very elegant solution. Since not normalized data is so common there must be a better solution.
Does anybody have an idea?
Regards
fhh
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962675#3962675
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962675
18 years, 5 months
[JBoss Messaging] - Re: Removing a MessageListener doesn't remove its associated
by davidrh
Hi Tim,
I think this would be the correct behaviour if there were not enough items on the queue for all threads to process. We've noticed that messaging has an affinity for the first thread when the load is light. In this case, though, we've checked the queue using the JMX console and there are lots of messages waiting to be processed on the queue that is reported as stopped. In fact, because some of the listeners have stopped the queue is actually starting to back up, as there are not as many threads working it any more.
These stopped listeners never seem to recover - we've left them overnight in our application but they never come back.
Just out of interest, how to you enable round robin dispatching to the listeners? This would make it easier for us to determine if every listener is doing its fair share, or whether some are slacking off.
Thanks,
David
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962674#3962674
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962674
18 years, 5 months
[Tomcat, HTTPD, Servlets & JSP] - Forwarding apache -> jboss -> jboss
by pmm258
In the screnaio where there is an apache in a DMZ forwarding to a known JBoss AJP13 port using mod-jk. This is works fine as per doco.
We have scenario where we deploy an application to another 'offline' jboss instance with different ports and when testing is complete and ready for deployment switch we have to change the worker.properties settings on DMZ apache server.
The DMZ apache server is under the control of another section, making changes more difficult.
Is it possible to have an intermediate JBoss instance always listening on a known AJP port (say 9002) for the DMZ apache server, to forward to the real JBoss instance on a port specified in the intermediate JBoss instance.
Changing the intermediate JBoss to forward to the different port would be more under our control.
Are there any other options in doing this 2 step forwarding ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962668#3962668
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962668
18 years, 5 months
[EJB 3.0] - Re: Changing default InvokerLocator port (ejb3-deployer)
by ALRubinger
I'm also having the same problem.
I have 2 server instances. Server Instance A is using the default ports as specified by sample-bindings.xml. Server Instance B is using the "ports-01" configuration:
<service-config name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3"
| delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
| <delegate-config>
| <attribute name="InvokerLocator">socket://${jboss.bind.address}:3973</attribute>
| </delegate-config>
| <binding port="3973"/>
| </service-config>
When running both server instances at the same time, I receive a NotFoundInDispatcherException when attempting to execute a method on my EJB3 stub (I obtain the stub just fine). When running only Server Instance B, I get the following connect exception:
org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection.
| at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:267)
| at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
| at org.jboss.remoting.Client.invoke(Client.java:525)
| at org.jboss.remoting.Client.invoke(Client.java:488)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.service.ServiceRemoteProxy.invoke(ServiceRemoteProxy.java:92)
| at $Proxy0.encrypt(Unknown Source)
| at com.ninem.rx.api.encryption.EncryptionDelegate.encrypt(EncryptionDelegate.java:54)
| at com.ninem.rx.api.encryption.EncryptionDelegateTests.testRoundtripEncryption(EncryptionDelegateTests.java:33)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at junit.framework.TestCase.runTest(TestCase.java:164)
| at junit.framework.TestCase.runBare(TestCase.java:130)
| at junit.framework.TestResult$1.protect(TestResult.java:110)
| at junit.framework.TestResult.runProtected(TestResult.java:128)
| at junit.framework.TestResult.run(TestResult.java:113)
| at junit.framework.TestCase.run(TestCase.java:120)
| at junit.framework.TestSuite.runTest(TestSuite.java:228)
| at junit.framework.TestSuite.run(TestSuite.java:223)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
| Caused by: java.net.ConnectException: Connection refused: connect
| at java.net.PlainSocketImpl.socketConnect(Native Method)
| at java.net.PlainSocketImpl.doConnect(Unknown Source)
| at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
| at java.net.PlainSocketImpl.connect(Unknown Source)
| at java.net.SocksSocketImpl.connect(Unknown Source)
| at java.net.Socket.connect(Unknown Source)
| at java.net.Socket.connect(Unknown Source)
| at java.net.Socket.<init>(Unknown Source)
| at java.net.Socket.<init>(Unknown Source)
| at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:535)
| at org.jboss.remoting.transport.socket.SocketClientInvoker.getConnection(SocketClientInvoker.java:471)
| at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:263)
| ... 30 more
|
|
Proving my client can obtain a stub from Server Instance B, but when executing...something's still referring to my default ports that run Server Instance A.
All insight appreciated.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962664#3962664
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962664
18 years, 5 months