[JNDI/Naming/Network] - Getting JNDI context fails
by SchlauFuchs
Hello,
I have a problem connecting my EJB3 client app to a JBoss server. In my development I had no problems connecting the server, as long as it was on the same machine with my client. Recently I switched to a remote JBoss server and since then I can't get my client working. Each time I try to connect I get an exception (client side) telling me that it can't connect to 127.0.0.2 (RMISocketException or such, haven't the stack trace with me.) The server is standalone, just the latest 4.0.4 EJB3-default installation. My app is deployed without problems. Firewall is disabled. If I shut down the server the exception is another, so it looks like something in the RMI handshake is failing. My jndi.properties file looks like a typical example just the server name replaced.
Any suggestions?
Kai
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969899#3969899
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969899
19 years, 7 months
[JCA/JBoss] - Re: How to access the configured datasource
by weston.price＠jboss.com
anonymous wrote :
|
| 1, how can I get the datasource object so to get a connection ? Since my web app is in the save JVM, could i get the datasource directly without a jndi lookup (may fetch the datasource mbean directly ?)? some code snippet will be really appreciated.
|
|
Being in VM has nothing to do with it. JNDI is the *only* way to look up the managed object. Your choice of how you do this depends:
You can always look up the object directly in JNDI
InitialContext initCtx = new InitialContext();
DataSource ds = (DataSource)initCtx.lookup("java:/PostgresDS");
Note the use of the "java:/" qualifier in the lookup. DataSources are, by default, bound into the java: namespace and are meant to be used within the context of JBoss and not remotely (ie by a thin Client). Note, there is a way to disable this and use it outside of the container but it is *not*, and I cannot stress this more emphatically, *not* recommended.
The other approach is to use a resource-ref in your web.xml/ejb-jar.xml file. This introduces a logical binding between a name and a raw jndi name. Consult the relevant J2EE specifications for more information.
anonymous wrote :
| 2,Is the database connections REALLY been pooled ,according the config like above ?
|
Yes.
anonymous wrote :
| 3,how to config to let jboss server initiate serveral database connection when startup?
|
JBoss 4.0.5 introduces a option to JBoss/JCA. The deault pool behavior does not construct managed connections on startup but rather, uses lazy initialization. The option allows the pool to prefill to the mininum allowance. Note, this can only be used for pools with the criteria of 'ByNothing'.
See
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigDataSources
and
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossJCAPooling
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969896#3969896
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969896
19 years, 7 months
[JBossCache] - Eviction - forcibly?
by suppyam
Hi -
I am not sure if I understood this right, so please go ahead and hit me up if I am wrong!! :)
The Eviction policy specifies when a node should be removed from the cache. There are various algorithms implemented. For example, the LRU - where the least recently used node is evicted after an idle time of 'timeToLiveSeconds'.
I am not sure if I missed this in the documentation, but what I need is a forcible eviction of all nodes from the cache, and a fresh reload. For example, after 2 hours, all nodes must be recached. I thought maxAgeSeconds would be ideal for this (maxAgeSeconds = 7200 for example, would mean that if wakeUpIntervalSeconds = 7201, then all these nodes would be swept away.
However, I also heard that parameter has now been deprecated. Is this right? If so, how do I go about achieving this?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969894#3969894
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969894
19 years, 7 months
[JCA/JBoss] - Re: XA Connection error
by weston.price＠jboss.com
Let me see if I can explain this a bit more clearly:
In your case, it does not appear that you are leveraging CMT or using the UserTransaction object from JNDI to start/commit a transaction. If that is indeed the case, you are going to want to use the
<no-tx-datasource>
Using this requires you to do the setAutoCommit(false) and commit explicitly, otherwise, ever statement issued will be done in the context of a seperate JDBC transaction. In that scenario your *code* was correct, but the type of datasource was wrong.
If you wanted to get away from managing your own transactions and leverage J2EE transaction management there are generally two approaches:
1) Use EJB (or some other declaractive transaction technology)
2) Use the UserTransaction object from JNDI to start/commit/rollback a transaction.
Typically #2 is used with straight Web (non-EJB) applications and looks something like this:
Servlet or JSP
| Context ic = new InitialContext();
| UserTransaction ut =
| (UserTransaction) ic.lookup("java:comp/UserTransaction");
| ut.begin();
| // access resources transactionally here
| ut.commit();
|
|
What we are talking about is transaction 'boundaries'. Technologies like EJB(2/3) allow you to declare transactions on method boundaries. Servlets/JSP do not, but allow access to the UserTransaction object (as can be seen above).
Note, either approach is neither 'right' or 'wrong', it's simply a matter of what your application requires. However, since you are running in a J2EE environment, CMT or UserTransaction delinated boundaries are typcially the preferred approach.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969890#3969890
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969890
19 years, 7 months