RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be java.lang.Object and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;) Does that really work? Can you get access to the value of the key later? I've combed over that part of the spec, but it's terribly vague about how deferred keys are supposed to work. I've never seen a container that documented them, I have never seen an example of them being used, and (until now) I have never known anyone to have tried them. Jeff Schnitzer [EMAIL PROTECTED]
SV: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
Hi, Have a look at the ATM sample shipped with the latest build, it uses them for the logs. With regards, Magnus Rydin -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] För Jeff Schnitzer Skickat: den 9 april 2002 09:30 Till: Orion-Interest Ämne: RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be java.lang.Object and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;) Does that really work? Can you get access to the value of the key later? I've combed over that part of the spec, but it's terribly vague about how deferred keys are supposed to work. I've never seen a container that documented them, I have never seen an example of them being used, and (until now) I have never known anyone to have tried them. Jeff Schnitzer [EMAIL PROTECTED]
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
Jeff - Yes, it really works. You can get access to the key value later by using getPrimaryKey on the instance. Cheers Ray Jeff Schnitzer [EMAIL PROTECTED] wrote: From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be "java.lang.Object" and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;)Does that really work? Can you get access to the value of the keylater? I've combed over that part of the spec, but it's terribly vagueabout how deferred keys are supposed to work. I've never seen acontainer that documented them, I have never seen an example of thembeing used, and (until now) I have never known anyone to have triedthem! .Jeff Schnitzer[EMAIL PROTECTED]Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax
[no subject]
Hi, I'm trying to set an error page in one of my web applications. To do this i have put this tag in the web.xml file: error-page error-code500/error-code location/error.html/location /error-page to catch all the 500 errors and redirect the user to an error page. It works when i put a plain html page but it doesn't when i put a jsp. is it possible to get a jsp instead of an html file? thanks.
R: Orion EJB container and SSL
I don't know how to do this. It could be possible, but there isn't documentation yet. As an alternative you could use SOAP. For example with GLUE you can use SSL to connect from a Java client to your EJB. Have a look at this articles: http://kb.atlassian.com/content/tutorials/finsiel/ejbsoap.jsp http://www.themindelectric.com/products/glue/docs/glue/guide/integrations/or ion/introduction.html http://www.themindelectric.com/products/glue/docs/glue/guide/security/ssl.ht ml you can download GLUE standard here: -Messaggio originale- Da: Sorin Pop [mailto:[EMAIL PROTECTED]] Inviato: venerdì 5 aprile 2002 11.31 A: Orion-Interest Cc: Pop Lucian Marius Oggetto: Fw: Orion EJB container and SSL Hey, is there anybody out there who can tell me something about this?! I've sent this more than a week ago, and I got no feedback whatsoever. If I'm talking bullshit (e.g the question is stupid or something like that), at least tell me _that_ somebody! But, please, somebody say something to it... - Original Message - From: Sorin Pop [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, March 29, 2002 3:21 PM Subject: Orion EJB container and SSL Is it possible to use SSL with the EJB container of the Orion server? For example the client is a standalone Java application that makes only RMI-IIOP calls to EJB-s (no JSP, no servlets, no HTML involved) in the EJB container. And I want to do this with security in mind, for example using SSL. Is it possible? (I read that it is possible to use SSL with simple RMI applications, or with a web application in the Orion server, but I would like to use Orion server's EJB container only...).
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
One comment on BMP performance mentioned in this thread. Applying the Fat-Key pattern may allow you to bulk load BMP entities from database with1 query instead of N+1. Tibor -Original Message-From: Ray Harrison [mailto:[EMAIL PROTECTED]]Sent: Tuesday, April 09, 2002 1:30 PMTo: Orion-InterestSubject: RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence Jeff - Yes, it really works. You can get access to the key value later by using getPrimaryKey on the instance. Cheers Ray Jeff Schnitzer [EMAIL PROTECTED] wrote: From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be "java.lang.Object" and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;)Does that really work? Can you get access to the value of the keylater? I've combed over that part of the spec, but it's terribly vagueabout how deferred keys are supposed to work. I've never seen acontainer that documented them, I have never seen an example of thembeing used, and (until now) I have never known anyone to have triedthem! .Jeff Schnitzer[EMAIL PROTECTED] Do You Yahoo!?Yahoo! Tax Center - online filing with TurboTax
Re: JDBC try/catch Pitfall ***MUST READ***
try
{
if(rs != null)
rs.close();
if(ps != null)
ps.close();
if(conn != null)
conn.close();
}
catch(SQLException sqle)
{
sqle.printStackTrace();
}
You do not make it clear, but if either rs.close() or ps.close()
has an exception, then conn.close() will never be called. Could
that be your issue?
In a finally, I usually try/catch each of those closes individually
to avoid just such a problem.
tim.
Re: [orion-interest]Re: JDBC try/catch Pitfall ***MUST READ***
Or use finally, which practically guarantees closure no matter what
On 9/4/02 2:31 pm, Tim Endres [EMAIL PROTECTED] wrote:
try
{
if(rs != null)
rs.close();
if(ps != null)
ps.close();
if(conn != null)
conn.close();
}
catch(SQLException sqle)
{
sqle.printStackTrace();
}
You do not make it clear, but if either rs.close() or ps.close()
has an exception, then conn.close() will never be called. Could
that be your issue?
In a finally, I usually try/catch each of those closes individually
to avoid just such a problem.
tim.
Re: JDBC try/catch Pitfall ***MUST READ***
try {
...
return;
} catch () {}
finally {
// must always come here per the Java VM spec
// else it's a bug
// Not calling the instance obj ref methods is a serious bug IMHO
}
To me this looks like a bug not an odd side effect.
What's your operating environment? Linux?
curt
RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence
I probably should have phrased my question a little differently: Is this guaranteed to work on any J2EE-compliant appserver? Jeff -Original Message- From: Ray Harrison [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:30 AM To: Orion-Interest Subject: RE: [orion-interest]CMP/BMP and standard JDBC, speed is of essence Jeff - Yes, it really works. You can get access to the key value later by using getPrimaryKey on the instance. Cheers Ray Jeff Schnitzer [EMAIL PROTECTED] wrote: From: Simon Stewart [mailto:[EMAIL PROTECTED]] Forgive me, but what about the case where you just set the prim-key-class to be java.lang.Object and don't specify a managed primary key field in your ejb-jar.xml file? While that's not the world's most advanced method for automatically generating primary keys, it's there, and it does work Of course, I have no idea how to refer to this autogenerated primary key using EJB-QL, but that's beside the point ;) Does that really work? Can you get access to the value of the key later? I've combed over that part of the spec, but it's terribly vague about how deferred keys are supposed to work. I've never seen a container that documented them, I have never seen an example of them being used, and (until now) I have never known anyone to have tried them! . Jeff Schnitzer [EMAIL PROTECTED] _ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax
Re: JDBC try/catch Pitfall ***MUST READ***
This site demonstrates the pitfalls with using returns finally:
http://www.cs.arizona.edu/sumatra/hallofshame/
It seems like this behaviour is not specified by the Java Language
Specification.
Cheers,
Scott
Greg Davis wrote:
This deals with try/catch blocks and finallys. I always believed that no
matter what a finally block is always called. While this seems to remain
true, it does not seem to necessarily properly call the code within the
block. In the section below I have some code and explanation of how a
finally gets called, but does not execute the code within.
There seems to be an issue with closing a JDBC connection if a method
returns in the middle of the try/catch block. It seems to call the finally,
but does not close the connection. It does seem to call static methods like
System.out.println() perfectly fine. I don't know if it being static has
anything to do with it. I haven't researched it too far since it was really
hard to find. First off you have to have a Factory like a ConnectionPool
that spawns out inscances of an object for other classes to use. Then it
must need to have the user close it's connection at some point so the
Factory can control resources. The only example I really have on hand is a
JDBC connection pool in a J2EE app server. This is where the problem occurd
for us. If the methods returns are moved outside the try/catch block, the
Connection.close() happens properly and the ConnectionPool does not
complain.
I realize the getColumnClose() is the better way to implement the code
ayway, but I wanted to show everyone this problem in case they accidentally
do it in their code somewhere. Any returns in the try or catches seemed to
make the finally not be properly executed. I seem to remember some wierd
rule about this at JavaOne last year, but my head is still racing from all
that information. :-)
Any comments?
package test;
import java.sql.*;
import javax.sql.DataSource;
import javax.naming.*;
/**
* pTitle: TryCatchTest/p
* pDescription: This is a test application for try/catch problem. If
using
* a Connection Pool in JDBC and you try to return a value within a
try/catch
* that is inside a method, the finally of that try/catch is not completely
run.
* It seems to go through the finally(I.E. Sytem.out.println() works, but
the
* Connection.close() is either never called or not executed. If the
return
* is moved to the outside of the catch block, the connection is properly
closed.
* br
* We found this because a J2EE server which had a connection pool was
telling
* us we were not closing our connections. I dn't know if there is some
rule that
* when a return has been called only static methods or something like
that can
* be called./p
* pCopyright: Copyright (c) 2002/p
* pCompany: Western Electronics /p
* @author a href=mail:[EMAIL PROTECTED]Greg Davis/a
* @version 1.0
*/
public class TryCatchTest
{
Context jndiContext;
public TryCatchTest()
{
try
{
jndiContext = new InitialContext();
}
catch(NamingException ne)
{}
}
public String getColumnNoClose()
{
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try
{
String sql =SELECT table_name FROM sequence;
conn
=((DataSource)jndiContext.lookup(jdbc/mySourceDS)).getConnection();
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
if(rs != null rs.next())
{
//This return causes the ?non-static? code within the finally to not
to be run.
return rs.getString(table_name);
}
//same here, the finally ?non-static? code is not called.
return null;
}
catch(NamingException ne)
{
//same here, the finally ?non-static? code is not called.
return null;
}
catch(SQLException sqle)
{
sqle.printStackTrace();
//The same problem occurs here. The finally ?non-static? code is not
called
return null;
}
finally
{
//This system out works, but the conn.close() does not. The only way
I
//know how to check this is to create a ConnectionPool yourself that
watches
//the connections it spawns out, or user a pre-built one that does the
same.
//We use Orion 1.5.4 J2EE App server (free for development). if you
want
//to test this out.
System.out.println(Finally called in noClose());
try
{
if(rs != null)
rs.close();
if(ps != null)
ps.close();
if(conn != null)
conn.close();
}
catch(SQLException sqle)
{
sqle.printStackTrace();
}
}
}
public String getColumnClose()
{
String returnValue = null;
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try
{
String sql =SELECT
Re: timed events
Get Sims Computing Inc product called Flux. You will need to set the times via a servlet or application, but it provides the timer or clock that your're writing about. http://www.simscomputing.com/ On Wednesday 13 March 2002 08:06 am, you wrote: Perhaps via a croned java client? //Johan - Original Message - From: Casper Højstrup [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 10:20 AM Subject: timed events This more of a regular EJB question, I suppose. I need to initiate some specific tasks and specific times in my application, since the application server aren't multithreaded(so to speak), and the usage of threads is not recommended, I cannot make a simple timer, that will initiate the appropriate procedures at a given time. How do one solve such problems in an EJB application ? Regards .
Re: JDBC try/catch Pitfall ***MUST READ***
To be honest, having implemented compilers and interpretters, the for
and while loop examples that they provide seem entirely logical. The
cases, in fact, are similar to saying this statement is false, and Java
would have to specify specific behavior for these cases.
I still find it very difficult to believe that the close() method is
not called for no reason other than being in a finally block. However,
I wonder if it might be related to the finalizer thread issue that
is raised on the page you cite.
tim.
This site demonstrates the pitfalls with using returns finally:
http://www.cs.arizona.edu/sumatra/hallofshame/
It seems like this behaviour is not specified by the Java Language
Specification.
Cheers,
Scott
Greg Davis wrote:
This deals with try/catch blocks and finallys. I always believed that no
matter what a finally block is always called. While this seems to remain
true, it does not seem to necessarily properly call the code within the
block. In the section below I have some code and explanation of how a
finally gets called, but does not execute the code within.
There seems to be an issue with closing a JDBC connection if a method
returns in the middle of the try/catch block. It seems to call the finally,
but does not close the connection. It does seem to call static methods like
System.out.println() perfectly fine. I don't know if it being static has
anything to do with it. I haven't researched it too far since it was really
hard to find. First off you have to have a Factory like a ConnectionPool
that spawns out inscances of an object for other classes to use. Then it
must need to have the user close it's connection at some point so the
Factory can control resources. The only example I really have on hand is a
JDBC connection pool in a J2EE app server. This is where the problem occurd
for us. If the methods returns are moved outside the try/catch block, the
Connection.close() happens properly and the ConnectionPool does not
complain.
I realize the getColumnClose() is the better way to implement the code
ayway, but I wanted to show everyone this problem in case they accidentally
do it in their code somewhere. Any returns in the try or catches seemed to
make the finally not be properly executed. I seem to remember some wierd
rule about this at JavaOne last year, but my head is still racing from all
that information. :-)
Any comments?
package test;
import java.sql.*;
import javax.sql.DataSource;
import javax.naming.*;
/**
* pTitle: TryCatchTest/p
* pDescription: This is a test application for try/catch problem. If
using
* a Connection Pool in JDBC and you try to return a value within a
try/catch
* that is inside a method, the finally of that try/catch is not completely
run.
* It seems to go through the finally(I.E. Sytem.out.println() works, but
the
* Connection.close() is either never called or not executed. If the
return
* is moved to the outside of the catch block, the connection is properly
closed.
* br
* We found this because a J2EE server which had a connection pool was
telling
* us we were not closing our connections. I dn't know if there is some
rule that
* when a return has been called only static methods or something like
that can
* be called./p
* pCopyright: Copyright (c) 2002/p
* pCompany: Western Electronics /p
* @author a href=mail:[EMAIL PROTECTED]Greg Davis/a
* @version 1.0
*/
public class TryCatchTest
{
Context jndiContext;
public TryCatchTest()
{
try
{
jndiContext = new InitialContext();
}
catch(NamingException ne)
{}
}
public String getColumnNoClose()
{
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try
{
String sql =SELECT table_name FROM sequence;
conn
=((DataSource)jndiContext.lookup(jdbc/mySourceDS)).getConnection();
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
if(rs != null rs.next())
{
//This return causes the ?non-static? code within the finally to not
to be run.
return rs.getString(table_name);
}
//same here, the finally ?non-static? code is not called.
return null;
}
catch(NamingException ne)
{
//same here, the finally ?non-static? code is not called.
return null;
}
catch(SQLException sqle)
{
sqle.printStackTrace();
//The same problem occurs here. The finally ?non-static? code is not
called
return null;
}
finally
{
//This system out works, but the conn.close() does not. The only way
I
//know how to check this is to create a ConnectionPool yourself that
watches
//the connections it spawns out, or user a pre-built one that does the
same.
RE: JDBC try/catch Pitfall ***MUST READ***
Wasn't there some other code in the finally clause which could throw another
SQLException? This would explain why some code got executed while the rest
did not. By the way, the javadoc says:
close
public void close()
throws SQLExceptionReleases a Connection's database and JDBC
resources immediately instead of waiting for them to be automatically
released.
Note: A Connection is automatically closed when it is garbage collected.
Certain fatal errors also result in a closed Connection.
Hmmm, so it cleans up after itself if there is no statement open (at least
in theory), but everywhere I look people recommend cleaning up
programmatically. I am not happy with jdbc anyway, it's hard to avoid
repetitive code, because you loose the ResultSet as soon as you close the
statement, making it impossible to call a method which just interacts the
database and then lets you do what you want with the resultset while the
connection is free for another access (with the exception of SELECT of
course). One could make a copy of the ResultSet, but if you have 10,000+
rows you need to process, this becomes a performance nightmare.
If anybody has a better suggestion, I'd be eager to listen! Just wrote a few
1000 lines of sql code, very boring ...
-Original Message-
From: Curt Smith [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 09, 2002 1:33 PM
To: Orion-Interest
Subject: Re: JDBC try/catch Pitfall ***MUST READ***
try {
...
return;
} catch () {}
finally {
// must always come here per the Java VM spec
// else it's a bug
// Not calling the instance obj ref methods is a serious bug IMHO
}
To me this looks like a bug not an odd side effect.
What's your operating environment? Linux?
curt
RE: JDBC try/catch Pitfall ***MUST READ***
I personally follow the old school of thought, 1 entry, 1 exit...while this
was probably intended to describe the entry/exit points of a program itself,
I use this same idea when coding...rather then returning in the middle of a
block of code, I generally try and return at the end, while this can
sometimes increase the complexity of the code, it generally makes it easier
to read and follow...
However, I think you problem relates more to what's going on in the final
block then anywhere else...each close statement should be trapped in their
own try/catch block (as mentioned before), while this increases the amount
of code, it ensures that each statement can be called...
Shane
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott Farquhar
Sent: Wednesday, 10 April 2002 08:16 am
To: Orion-Interest
Subject: Re: JDBC try/catch Pitfall ***MUST READ***
This site demonstrates the pitfalls with using returns finally:
http://www.cs.arizona.edu/sumatra/hallofshame/
It seems like this behaviour is not specified by the Java Language
Specification.
Cheers,
Scott
Greg Davis wrote:
This deals with try/catch blocks and finallys. I always believed that no
matter what a finally block is always called. While this seems to remain
true, it does not seem to necessarily properly call the code within the
block. In the section below I have some code and explanation of how a
finally gets called, but does not execute the code within.
There seems to be an issue with closing a JDBC connection if a method
returns in the middle of the try/catch block. It seems to call the
finally,
but does not close the connection. It does seem to call static methods
like
System.out.println() perfectly fine. I don't know if it being static has
anything to do with it. I haven't researched it too far since it was
really
hard to find. First off you have to have a Factory like a ConnectionPool
that spawns out inscances of an object for other classes to use. Then it
must need to have the user close it's connection at some point so the
Factory can control resources. The only example I really have on hand is a
JDBC connection pool in a J2EE app server. This is where the problem
occurd
for us. If the methods returns are moved outside the try/catch block,
the
Connection.close() happens properly and the ConnectionPool does not
complain.
I realize the getColumnClose() is the better way to implement the code
ayway, but I wanted to show everyone this problem in case they
accidentally
do it in their code somewhere. Any returns in the try or catches seemed
to
make the finally not be properly executed. I seem to remember some wierd
rule about this at JavaOne last year, but my head is still racing from all
that information. :-)
Any comments?
package test;
import java.sql.*;
import javax.sql.DataSource;
import javax.naming.*;
/**
* pTitle: TryCatchTest/p
* pDescription: This is a test application for try/catch problem. If
using
* a Connection Pool in JDBC and you try to return a value within a
try/catch
* that is inside a method, the finally of that try/catch is not
completely
run.
* It seems to go through the finally(I.E. Sytem.out.println() works, but
the
* Connection.close() is either never called or not executed. If the
return
* is moved to the outside of the catch block, the connection is properly
closed.
* br
* We found this because a J2EE server which had a connection pool was
telling
* us we were not closing our connections. I dn't know if there is some
rule that
* when a return has been called only static methods or something like
that can
* be called./p
* pCopyright: Copyright (c) 2002/p
* pCompany: Western Electronics /p
* @author a href=mail:[EMAIL PROTECTED]Greg Davis/a
* @version 1.0
*/
public class TryCatchTest
{
Context jndiContext;
public TryCatchTest()
{
try
{
jndiContext = new InitialContext();
}
catch(NamingException ne)
{}
}
public String getColumnNoClose()
{
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try
{
String sql =SELECT table_name FROM sequence;
conn
=((DataSource)jndiContext.lookup(jdbc/mySourceDS)).getConnection();
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
if(rs != null rs.next())
{
//This return causes the ?non-static? code within the finally to
not
to be run.
return rs.getString(table_name);
}
//same here, the finally ?non-static? code is not called.
return null;
}
catch(NamingException ne)
{
//same here, the finally ?non-static? code is not called.
return null;
}
catch(SQLException sqle)
{
sqle.printStackTrace();
//The same problem occurs here. The finally ?non-static? code is
not
called
return null;
}
finally
{
