RE: default.jsp bug (duplicate requests)
If I were to guess your problem is not with orion, but rather with your settings for cache expiration in the JSP pages. response.setDateHeader (Expires, 1); //prevents caching at the proxy Try replacing your cache prevention section with: % response.setHeader(Pragma, No-cache); response.setHeader(Cache-Control, no-cache); response.setDateHeader(Expires, 0); % or try removing it totally to confirm the error and set the browser to check for new pages on every hit at the client side. Regards, Manuel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Johnson Sent: Monday, April 01, 2002 7:00 AM To: Orion-Interest Subject: default.jsp bug (duplicate requests) I have discovered a bug with orion after enabling Content Advisor in both IE 5.5 and 6.0. The problem is that the default.jsp is being executed after every request, causing a duplicate erroneous request. I have created a simple test to duplicate the problem. I tested 1.5.2 and 1.5.4 which both have the problem. I also tested oc4j 1.0.2.2.1 which works fine. Below are the steps to reproduce the problem. 1. Create a default.jsp which contains the following lines: (The first few lines are to prevent caching): % response.setHeader(Cache-Control,no-store); //HTTP 1.1 response.setHeader(Pragma,no-cache); //HTTP 1.0 response.setDateHeader (Expires, 1); //prevents caching at the proxy server % %! static int x = 0; % % System.out.println(EXECUTING DEFAULT.JSP: x= + x);% %=This is default.jsp: x= + x++% 2. Create a test.jsp which contains the following lines (The first few lines are to prevent caching): % response.setHeader(Cache-Control,no-store); //HTTP 1.1 response.setHeader(Pragma,no-cache); //HTTP 1.0 response.setDateHeader (Expires, 1); //prevents caching at the proxy server % %! static int y = 0; % % System.out.println(EXECUTING TEST.JSP: y= + y);% %=This is test.jsp: y= + y++% 3. Place both files in the default-web-app folder (be sure to rename the index.html to index1.html so the default.jsp is used). 4. Start orion and issue a request for http://localhost/test.jsp. Below is the output I receive: C:\Prog\java\orion1_5_2java -jar orion.jar Orion/1.5.2 initialized EXECUTING TEST.JSP: y=0 EXECUTING DEFAULT.JSP: x=0 -- Duplicate request 5. Now issue a request for http://localhost/. Below is the output I receive: C:\Prog\java\orion1_5_2java -jar orion.jar Orion/1.5.2 initialized EXECUTING TEST.JSP: y=0 EXECUTING DEFAULT.JSP: x=0 EXECUTING DEFAULT.JSP: x=1 EXECUTING DEFAULT.JSP: x=2 -- duplicate request This is causing some problems for my site which I am about to deploy and I have been unable to find a solution. I will probably have to switch to an alternate server if I cannot resolve the problem. Any help would be appreciated. Thanks, Robert Johnson
FW: java.lang.OutOfMemoryError
our wonderful mailing list -Original Message- From: Manuel De Jesus [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 12:18 PM To: 'Orion-Interest' Subject: RE: java.lang.OutOfMemoryError I would recommend that first verify that the problem is not with your code ? Try using the bult in jvm profiling tools (do a search on www.javaworld.com they had a nice example of doing this. If you are sure that your code is fine (one way to test is to run everything over just http for a while if this is possible in your environment ?), then I would like to spare you manny hours of frustration by giving you my final analysis (console you by letting you know that you are not alone ... ;)): (as per my post yesterday) Orions https code is buggy from my experence with it. We rolled out https on orion and ran into quite a few problems. We were previously running resin with SSL enabled with no problems on a simpler site. The server overhead for orion running SSL is huge and we also had problems with the SSL site on orion sometimes going into some kind of loop and using 100% of the CPU. We had none of these problems without SSL enabled. We evetually bought an SSL accelerator and our site has been rock solid since then. If you are doing low volumes it might work, but if you want to get sleep at night I wouldn't recommend using it. I would seriously recommend getting an SSL accelerator, the load on our server went from 60% to 1-2% when we installed the accelerator. It's pretty much worth the money spent if you have a serious site. Orion is pretty good otherwise though (except for a few minor gripes I have about transaction isolation levels - it's not geared for a really huge finacials EJB site IMHO but you won't do any better on the price performance side). Just something else that might help from (http://www.caucho.com/products/resin/faq/ssl.xtp): Should I use JSSE or OpenSSL or Apache/IIS for SSL? We recommend avoiding JSSE if possible. It is slower than using bin/resin's OpenSSL support and does appear to be as stable as Apache or IIS (or Netscape/Zeus) for SSL support. In addition, JSSE is far more complicated to configure. While we've never received any problems with Resin using SSL from Apache or IIS, JSSE issues are fairly frequent. Even if you're using Apache/IIS for SSL support, you can still use Resin's standalone web server for non-SSL pages. Your resin.conf will need to list both a http port='80'/ and a srun port='6802'/. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of mars Sent: Tuesday, March 12, 2002 9:16 AM To: Orion-Interest Subject: java.lang.OutOfMemoryError Dear orion user : I got a problem I have a Orion Appcation Server Run on Linux run the http service and https service then after a few hours I got the message in server.log *-- java.lang.OutOfMemoryError no stack trace available *-- and the https service down but http service still running is the memory low to use or any possable cause? !!!my server have 1GB Ram!!!
RE: Random hiccups with Orion+https
Make sure you have the shared attribute set in both your web-site.xml configuration files for the secure and the non-secure sites. Orions https code is buggy from my experence with it. We rolled out https on orion and ran into quite a few problems. We were previously running resin with SSL enabled with no problems on a simpler site. The server overhead for orion running SSL is huge and we also had problems with the SSL site on orion sometimes going into some kind of loop and using 100% of the CPU. We had none of these problems without SSL enabled. We evetually bought an SSL accelerator and our site has been rock solid since then. If you are doing low volumes it might work, but if you want to get sleep at night I wouldn't recommend using it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Peltonen Sent: Monday, March 11, 2002 12:17 PM To: Orion-Interest Subject: Random hiccups with Orion+https Orion 1.4.7 + https (a test ssl cert from Thawte installed following the instructions at Atlassian site) is causing problems: You get thrown out of the applicaton now and then (randomly it seems). Without https the application works fine. Is Orion's https code buggy (should we use Apache as frontend instead), is there some known problems with some specific browsers etc or what is going on? Regards, Peter
RE: TX Was Null
I don't think that relying on your Entity Beans for front line data validation is a good design. As a rule of thumb to get the best performance in applications you want to validate as early as you can to save the trouble of having to process all the steps for a transaction only to find the data is invalid when you want to save things and use this to throw an error. In most app servers you usaully set transaction retries to at least 2 (incase there was a network/temporary error on the first attempt this increases the reliablity) - by throwing data validation exceptions at the EJB level you are looking at doing a TX twice before reporting the error ... terrible performance. What I have done in projects is to abstract validation to a set of Validation classes that are normal java classes which can be used on the jsp/ejb etc etc tier. These classes interact with the database via singleton caches allowing for dynamic validation updates (worth their weight in gold). This also means that the stand alone validation objects can be easily reused in other projects, expecially the rules that are generic enough :). Using a separate set of validation classes I would suggest: 1) Validate the TX at the point where it starts right up front if you are using jsp etc if this is an option. 2) Validate the TX in the actual session bean. We use a custom exception with a Vector of string mappings that allows us to complain about more than one error etc. 3) If you are really paranoid/have mutiple update points you can also validate at the entity bean and even a littel at the db level (not null, size etc). Since you are using a shared validation library, changing the validation is done in one place. In addition your application = 100 times faster since you are not rolling back transactions a million times over. And the big bonus is it will work on 99% of app servers. Regards, Manuel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, January 28, 2002 5:13 PM To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: TX Was Null We're coming up on our deployment date, so we're considering our deployment options (notably, at this point, JBoss and Orion). The system is running and working under JBoss, and I've been re-porting it to Orion so that we can do some testing, try and resolve some issues we had under Orion (for which we got some help from Atlassian that we haven't had a chance to try out yet). In the process, we've re-adjusted most or all of the finders, and fixed a few bugs here and there between what JBoss does and what Orion does. It's been enlightening, as usual. That said, we've run up against a brick wall. One of our transactional saves uses a session bean to save two entities in a combined declarative transaction. Each of these beans can throw validation exceptions when passed data that's meant to save. We have two unit tests, one which throws invalid data into the first object, and another which throws invalid data into the second object. The second object is relatively easy -- if it has problems, the session bean sets the transaction to rollback only, and lets the server do the rest of the work. This works under both Orion and JBoss as expected. If the first object fails, though, there are larger issues -- we still want to find out if there's a problem with the data being passed to the second object. Under JBoss, if we tried to do this in the same transaction, it complained that the transaction was already rolled back, which is sensible. So we put the validation method into a 'requires new' transaction. On JBoss, if the first object fails, the second one tests its data in a new transaction, gathers the validation errors, and rolls back. On Orion, this seems to create an exception: Testcase: testProgramRollback took 4.703 sec Caused an ERROR Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null; nested exception is: java.lang.InternalError: TX was null com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null at TransactionalSaver_StatelessSessionBeanWrapper176.saveProgramAndCaseStudy(Tr ansactionalSaver_StatelessSessionBeanWrapper176.java:104) at java.lang.reflect.Method.invoke(Native Method) at com.evermind._dh._gc(Unknown Source) at com.evermind._if.run(Unknown Source) at connection to localhost/127.0.0.1 as thesquareUser at com.evermind._cd.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(Unknown Source) at com.evermind._cd.invokeMethod(Unknown Source) at com.evermind._dn.invoke(Unknown Source) at __Proxy7.saveProgramAndCaseStudy(Unknown Source) at com.mediumone.thesquare.ejb.transactionalSaver.liveTest.TransactionalSaverTe st.testProgramRollback(TransactionalSaverTest.java:69) at java.lang.reflect.Method.invoke(Native Method)
RE: Transaction Isolation levels with orion and oracle ... no go
Thanks for the response ! I have used this approach and others before to handle distrubted transactions. Currently I have actually changed the system to use a stateless session bean with row locks for performing updates and BMP Entity Beans for reading only and setting attributes in the object that are not sensitive to update sequences. The biggest gripe/warning is according to the EJB spec if you specify transaction isolation = repeatable_read/serializable (oracle only supports serializable) the ejb container should perform this locking during a transaction thus saving you all the work of having to manually control the distributed transaction. I have tried various options in setting this up on orion, playing with exclusive read access etc etc - It simply doesn't work. If anyone has actually got this to work I would appreciate any feedback/help. If not I think you might want to remeber this for any big project that you are using orion for that is going to require multiple instances of orion - i.e orion's isolation levels don't work with oracle so you have to manually code support for this. Regards, Manuel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Friday, January 18, 2002 8:38 PM To: Orion-Interest Subject: RE: Transaction Isolation levels with orion and oracle ... no go Hi This may be what you might try. I believe your problem is due to STALE data in one of the clients. This is a problem for all apps, unless you lock rows on read, which is a bad idea. The way to solve it (Just one of many), is like this: - Ensure all your tables have a last_modified date type field (Version number field works to). - Ensure that all clients always load the last_modified date along with the displayed data, and sends it back with the request. (Assuming web app, but it translate to other types of clients) - In your session bean (or whereever you have coded the updates to the entity), have it check the entity beans last_modified date with the one stored in the client, if not the same, data has been modified out from under you, handle this whatever way you like. Hope thats clear. Bye. -Original Message- From: Manuel De Jesus [mailto:[EMAIL PROTECTED]] Sent: Friday, January 18, 2002 8:32 AM To: Orion-Interest Subject: Transaction Isolation levels with orion and oracle ... no go Hi All Just a follow up on my question about using two instances of orion and handeling distributed transactions. Scenario: A customer account object holds the balance for the customer and is a Container Managed Persistance Entity Bean. Customer accesses server 1 and loads customer account with balance = 10 Admin staff accesses server 2 and loads customer account with balance = 10 Customer buys 1 unit and balance is now 9. Admin staff passes a journal correction (ie add 1) and balance is now 11. A check on the database after this seqeunce and yup balance = 11. I have tested orion with the transaction isolation level =serializable which is the only other level that Oracle supports and this occurs. Is this an orion limitation or is there some setting/some way of getting around this ? Any help/input would be greatly appreciated. The only way around this serious problem I can think of is a complete re-write of EJBs to used Container managed persistance and manually control isolation with a version attribute (painful). Regards, Manuel ** THIS MESSAGE IS INTENDED ONLY FOR THE ADDRESSEE, IT MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. ANY UNAUTHORISED DISCLOSURE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE NOTIFY US IMMEDIATELY SO THAT WE MAY CORRECT OUR INTERNAL RECORDS. PLEASE THEN DELETE THE ORIGINAL EMAIL. THANK YOU **
Transaction Isolation levels with orion and oracle ... no go
Hi All Just a follow up on my question about using two instances of orion and handeling distributed transactions. Scenario: A customer account object holds the balance for the customer and is a Container Managed Persistance Entity Bean. Customer accesses server 1 and loads customer account with balance = 10 Admin staff accesses server 2 and loads customer account with balance = 10 Customer buys 1 unit and balance is now 9. Admin staff passes a journal correction (ie add 1) and balance is now 11. A check on the database after this seqeunce and yup balance = 11. I have tested orion with the transaction isolation level =serializable which is the only other level that Oracle supports and this occurs. Is this an orion limitation or is there some setting/some way of getting around this ? Any help/input would be greatly appreciated. The only way around this serious problem I can think of is a complete re-write of EJBs to used Container managed persistance and manually control isolation with a version attribute (painful). Regards, Manuel
RE: Simple question re caching/pooling of BMP Entity Beans
You can avoid the call. Using a combination of isModified, validity_timeout and transaction_isolation ... just play around with it for a bit. See the online Orion FAQ: http://www.orionserver.com/faq/ I am using CMP Entity beans and call many methods on it that do not modify the state of the bean. How can I help Orion figure out that I am not changing the state and that it does not need to talk to the database? Implement the method public boolean isModified() in your bean to return a boolean flag that you set each time you modify your bean and clear in ejbStore(). If isModified() returns false, Orion knows that it doesn't need to talk to the database Regards, Manuel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geoff Soutter Sent: Friday, January 11, 2002 7:13 AM To: Orion-Interest Subject: RE: Simple question re caching/pooling of BMP Entity Beans Hmm. Seems I am really getting myself confused. :-). I think I've got it now... I'm mistaking the db call in ejbFindByPrimaryKey with the db call in ejbLoad. Doh. So, the first time I call findByPrimaryKey, Orion calls ejbFindByPrimaryKey which goes to the database basically only to confirm the row hasn't been deleted. Then Orion calls ejbLoad which goes the the database again to load in the actual contents of the row. So, the row in question is accessed twice. Then, the second time, Orion still calls findByPrimaryKey, but avoids the ejbLoad. The thing is here, exclusive-write-access is set to true (by default), so why is Orion bothering to call findByPrimaryKey? Can't it just keep an internal primary key - ejb map and return the ejb instance directly? After all, if exclusive-write-access is on, the row can only be deleted by Orion itself... Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Geoff Soutter Sent: Friday, 11 January, 2002 9:09 AM To: Orion-Interest Subject: RE: Simple question re caching/pooling of BMP Entity Beans Hi Sergey, Thanks for the reply. I didn't explain it very clearly did I? What I meant was: However, it appears that it goes to the database (i.e. calls _ejbLoad_ in the Entity Bean's implementation) for every call to findByPrimaryKey, regardless of whether it has previously read the instance with the specified key before. Have you been able to get pooling of BMP entity beans working? Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sergey G. Aslanov Sent: Thursday, 10 January, 2002 6:29 PM To: Orion-Interest Subject: Re: Simple question re caching/pooling of BMP Entity Beans Hi Geoff Loading of beans have these stages: 1. calling ejbFindBy... to get the primKeys of the entities; 2. checking if entities with such keys are already pooled; 3. for every key checking: if not pooled - call ejbLoad, else - get instance from pool; As you see, ejbFindBy... are called always independently of entity is pooled or not. Thursday, January 10, 2002, 2:01:37 AM, you wrote: GS Hi there, GS I'm teaching myself how to use Orion and I've got a simple question GS about caching/pooling of BMP Entity Bean instances. GS I've created a simple app which lets me read a BMP Entity Bean GS through a Session Bean. I would expect that when I call GS findByPrimaryKey on my Entity Bean's home interface, Orion caches GS the instance it creates so that next time I call findByPrimaryKey GS for the same key, it just returns the instance it already has rather GS than creating a new one. However, it appears that it goes to the GS database (i.e. calls ejbFindByPrimaryKey in the Entity Bean's GS implementation) for every call to findByPrimaryKey, regardless of GS whether it has previously read the instance with the specified key GS before. GS I checked the list archive and it appears that someone has reported GS a similar problem a while back but there were no replies GS (http://www.mail-archive.com/orion-interest@orionserver.com/ms g17359 GS .htm GS l). GS I also checked the documentation and for orion-ejb-jar.xml it states GS that exclusive-write-access is true by default, and since I am not GS setting it I presume it's defaulting to true which should allow GS Orion to cache the entity beans. GS So, can anyone shed any light on how whether/how I can get Orion to GS cache BMP entity beans? GS Cheers GS Geoff -- Sergey G. Aslanov, CBOSS Group, Web-technologies department mailto:[EMAIL PROTECTED] tel: +7 095 7555655
RE: OrionRemoteException: Error (de-)serializing object:
Yeah you have to return an arraylist or a vector, i.e something that is
serializable. It is never a good idea to pass ResultSet objects around.
Although it is attractive in terms of changeability (eg adding more fields
etc) to use a ResultSet, it can become a nightmare when there are network
problems and you can leak connections if you don't handle the exceptions
properly.
If you are using ejb's then the whole idea is that the EJB is an object
version of the data so that you can work directly with the object. If you
want to use a ResultSet directly in the jsp (useful for reporting etc), just
open the connection to the database directly in the JSP and do your query
and close it again. If you are doing something more invovled you might want
to user a few beans/taglibs (there are some nice jdbc ones around) just to
stop your jsp pages from becomming a spiderweb.
Your DBManagerBean looks dangerous - there is a pretty good chance you are
going to leak connections. Rather use just a normal bean that you can
instatiate locally at the jsp side or the ejb side. Thus there is no need to
use an ejb to control connections.
Regards,
Manuel
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Andres Garcia
Hourcade
Sent: Wednesday, November 21, 2001 3:32 AM
To: Orion-Interest
Subject: OrionRemoteException: Error (de-)serializing object:
Hi, i am new in J2EE technology and i'm big troubles.
I have an intranet application (jsp ejb) running fine with version 1.4.0,
i am trying to deploy the same EAR in 1.5.2 version, but i get this error.
com.evermind.server.rmi.OrionRemoteException: Error (de-)serializing object:
org.gjt.mm.mysql.jdbc2.ResultSet; nested exception is:
java.io.NotSerializableException: org.gjt.mm.mysql.jdbc2.ResultSet
This error occurs when i return a ResultSet from a method executeQuery of
an EJB that manages de mysql db.
I have written many jsp, that are in production, and i woud not want to
modify them.
Is there any solution for this error ?
Can i solve this problem if i return a Vector, instead of a ResultSet ?
Many thanks in advance and best regards
Andres Garcia Hourcade
EJB
import java.rmi.*;
import java.util.*;
import javax.ejb.*;
import javax.naming.*;
import java.sql.*;
import javax.sql.*;
import javax.sql.DataSource;
// ejb que maneja archivos de log
import Log.*;
public class DbManagerBean implements SessionBean
{
transient SessionContext context;
transient Connection conn = null;
transient DataSource ds = null;
transient Statement st = null;
transient ResultSet rs = null;
public void getConnection(String datasource) throws RemoteException,
DbManagerException
{
try
{
InitialContext ictx = new InitialContext();
this.ds = (DataSource) ictx.lookup(datasource);
this.conn = this.ds.getConnection();
}
catch (Exception e)
{
throw new DbManagerException(e);
}
}
public void closeConnection() throws RemoteException, DbManagerException
{
try
{
this.conn.close();
}
catch (Exception e)
{
throw new DbManagerException(e);
}
}
public ResultSet executeQuery(String strsql, String logonuser) throws
RemoteException, DbManagerException
{
st = null;
rs = null;
try
{
//ResultSet.TYPE_SCROLL_INSENSITIVE,
//ResultSet.CONCUR_READ_ONLY
this.st = this.conn.createStatement();
try{
// logeo la consulta
InitialContext context = new InitialContext();
LogHome logHome = (LogHome)
javax.rmi.PortableRemoteObject.narrow(context.lookup(Log), LogHome.class);
Log log = logHome.create();
log.writeDebug(strsql, logonuser);
log.remove();
}
catch (Exception e)
{
throw new DbManagerException(e);
}
rs = this.st.executeQuery(strsql);
// the closing of a statement also closes all
// the resultsets asociated with the statement
st.close();
}
catch (SQLException e)
{
throw new DbManagerException(e, this.conn);
}
return (rs);
}
public void ejbPassivate(){
context = null;
conn = null;
ds = null;
st = null;
rs = null;
}
public void ejbActivate()
{
}
public void ejbRemove()
{
}
public void ejbCreate()
{
}
public void setSessionContext(SessionContext context)
{
this.context = context;
}
}
Transactions across a cluster Orion GURUS - please advise.
Hi All Has anyone actually tested orion transactions over a cluster ? I am looking at developing a CMP Entity Bean that stores an account balance for a customer. If this entity bean is deployed on a cluster of 4 servers and I have and admin person and the actual customer do transactions, will they be looking at the same object instance even if their requests are being served on different servers ? Will ACID be supported in this scenario ? I would greatly appreciate any help/advice on this. Regards, Manuel
Bean managed persistance - connection management.
I'm pretty new to EJBs and was wondering about connection pooling mechanism
used. In the J2EE reference implementation the examples of Bean managed
persistance (see below) obtains a reference to a datasource and then it
obtains a connection from the datasource when it is instantiated. The bean
then uses the connection for all database interactions, only calling the
close method when the bean is removed from the container. Does this mean
that for the duration of the existance of the Bean it maintains an open
connection to database ? If this is the case then that would mean if I had
1 beans I would have 1 open DB connections ... ?
Is there a reason why they do not cache the Datasource reference from the
lookup and do a ds.getConnection() in the store and load methods and then
call the con.close() after each is complete ? Does orion/app servers in
general use some kind of wrapper on the Connection object to perform the
pooling at a lower level through the Connection object ? Is there a better
way to handle the connections ... ?
Regards,
Manuel
Manuel De Jesus
Software Engineer - IT
Vodacom World Online (Pty) Ltd
80 Strand Street, Cape Town
[EMAIL PROTECTED]
http://www.worldonline.co.za
/*
*
* Copyright 2000 Sun Microsystems, Inc. All Rights Reserved.
*
* This software is the proprietary information of Sun Microsystems, Inc.
* Use is subject to license terms.
*
*/
import java.sql.*;
import javax.sql.*;
import java.util.*;
import javax.ejb.*;
import javax.naming.*;
public class AccountEJB implements EntityBean {
private String id;
private String firstName;
private String lastName;
private double balance;
private EntityContext context;
private Connection con;
private String dbName = java:comp/env/jdbc/AccountDB;
public void debit(double amount)
throws InsufficientBalanceException {
if (balance - amount 0) {
throw new InsufficientBalanceException();
}
balance -= amount;
}
public void credit(double amount) {
balance += amount;
}
public String getFirstName() {
return firstName;
}
public String getLastName() {
return lastName;
}
public double getBalance() {
return balance;
}
public String ejbCreate(String id, String firstName,
String lastName, double balance)
throws CreateException {
if (balance 0.00) {
throw new CreateException
(A negative initial balance is not allowed.);
}
try {
insertRow(id, firstName, lastName, balance);
} catch (Exception ex) {
throw new EJBException(ejbCreate: +
ex.getMessage());
}
this.id = id;
this.firstName = firstName;
this.lastName = lastName;
this.balance = balance;
return id;
}
public String ejbFindByPrimaryKey(String primaryKey)
throws FinderException {
boolean result;
try {
result = selectByPrimaryKey(primaryKey);
} catch (Exception ex) {
throw new EJBException(ejbFindByPrimaryKey: +
ex.getMessage());
}
if (result) {
return primaryKey;
}
else {
throw new ObjectNotFoundException
(Row for id + primaryKey + not found.);
}
}
public Collection ejbFindByLastName(String lastName)
throws FinderException {
Collection result;
try {
result = selectByLastName(lastName);
} catch (Exception ex) {
throw new EJBException(ejbFindByLastName +
ex.getMessage());
}
if (result.isEmpty()) {
throw new ObjectNotFoundException(No rows found.);
}
else {
return result;
}
}
public Collection ejbFindInRange(double low, double high)
throws FinderException {
Collection result;
try {
result = selectInRange(low, high);
} catch (Exception ex) {
throw new EJBException(ejbFindInRange: +
ex.getMessage());
}
if (result.isEmpty()) {
throw new ObjectNotFoundException(No rows found.);
}
else {
return result;
}
}
public void ejbRemove() {
try {
deleteRow(id);
} catch (Exception ex) {
throw new EJBException(ejbRemove: +
ex.getMessage());
}
}
public void setEntityContext(EntityContext context) {
this.context = context;
try {
makeConnection();
} catch (Exception ex) {
throw new EJBException(Unable to connect to database. +
ex.getMessage());
}
}
public void unsetEntityContext() {
try {
con.close();
} catch (SQLException ex) {
throw new EJBException(unsetEntityContext: + ex.getMessage());
}
}
public void ejbActivate() {
id
RE: UNSUSCRIBE
Freggin idiot ... *no offence* *G* Does it really take that much to spend 2 seconds to check your spelling on UNSUBSCRIBE ! Maybe a fool proof web interface to allow for unsubscribing like we would have for a john doe user ... would expect more from a developer though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ken Eisner Sent: Thursday, July 05, 2001 2:47 PM To: Orion-Interest Subject: UNSUSCRIBE UNSUSCRIBE
