Re: Session EJB Accessibility
I am sure a dirty read is when an object has an old set of values when compared to the database. This does happen in optimistic concurrency control. Dan - Original Message - From: "Vidur Dhanda" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 7:52 AM Subject: Re: Session EJB Accessibility I believe Orion uses pessimistic concurrency control. However, I don't think optimistic concurrency control would allow dirty reads -- I understand a dirty read to imply a transaction seeing the uncommitted state of another transaction. Vidur Jeff Schnitzer wrote: From: Gary Shea [mailto:[EMAIL PROTECTED]] I could use a little help here. My limited understanding of entity beans suggests that if I create an EB using a particular key value, as long as I refer only to that same key value there would only be one instance of the EB. Is that not true because of optimizations that allow bean pooling of a particular EB for a particular value of that EB's primary key if 'optimistic concurrency' is assumed? What _is_ 'optimistic concurrency' anyway, he said, exposing the full depth of his ignorance... This article is good explanation: http://theserverside.com/resources/news1.jsp#dev The details are spelled out in sections 9.6.9 and 9.6.10 of the EJB2.0 spec, but it's pretty esoteric. Basically: With pessimistic concurrency, the app server ensures that only a record is only represented by a single entity bean and serializes transactions on that bean. With optimistic concurrency, the app server allows a bean instance to be created for each transaction. This is much faster (no waiting for the other transaction to commit) but allows the possibility of dirty reads. It's analagous to isolation levels in the database. I'm not quite sure what Orion does, and I wish someone would chime in with a comment or two in this respect. I'm about to decompile the counter.jar example in hope of finding some clues. Jeff -- Vidur Dhanda Active Solutions tel: 617/566-1252 [EMAIL PROTECTED] www.active-solutions-inc.com
Re: App that runs on OrionServer but throws a java.lang.VerifyError on weblogic 6.0
What does (Is your agruement RMI-IIOP valid) mean?, this class is used from a javabean used from a JSP. Its parameters are two classes from my own and java.lang.String from Sun. We are not using neither clustering neither persistant sessions (at least I think that this is the default configuration) Something that shock me is that it runs fine under Orion, then what could be happening? Matt Bauer wrote: Is your agruement RMI-IIOP valid? M Ismael Blesa Part wrote: We have developed a web application that works fine under OrionServer. It has JSP, JavaBeans and Taglibs. Now we are testing with Bea Weblogic and there are some strange errors thrown by the server. It complains about (java.lang.VerifyError: (class: com/test/logic/integration/connectors/BeanConnector, method: connect signature: com/test/logic/MyData;Lcom/test/logic/Environment;Ljava/lang/String;)V) Incompatible object argument for function call) It is a very strange error, I have compiled all my code with javac (1.3.0_01) and also with jikes last version. I have changed also bea weblogic to point jdk to my installed jdk. The best of all this strange error is that this method is not called. ie: looking on the print messages I have put on the code, execution stops before the invocation of this method. I think that this error comes when the java virtual machine tries to load this class. Anybody has any idea about what is causing this error to appear? Regards, Ismael ([EMAIL PROTECTED])
SV: taglibs
Title: RE: taglibs
Are
you in production with 1.3.8 ?
Otherwize I would strongly suggest that you update your server to a later
version.
If the
problems persists, please package it into a WAR and include it in a reply so
that we can try it out.
WR
-Ursprungligt meddelande-Från: Grant Doran
[mailto:[EMAIL PROTECTED]]Skickat: den 30 januari 2001
14:56Till: Orion-InterestÄmne: RE:
taglibs
I had this problem early on. Go back
to basics to start with. Your first step is to refer
to the class directly and not through a jar file.
Try this:
1. Get rid of the taglib tag in the web.xml
2. Change the URI in the taglib.tld to:
uri/ 3. When using the TAGLLIB directive in
the JSP, refer to it using a relative or vitrual URL that you know is
correct. eg: %@ taglib
uri="/taglib/jet.tld" prefix="jet" %
This should work. One of the problems
that I've found is that using more elegant referencing to tags and
taglibraries is not portable. For instance, when I
tried to port our EAR file to Weblogic 6.0, I spent the best part of a day
trying to get the taglibrary to work even though the whole application runs
fine on Orion.
By the time I had written Weblogic off, their support people
finally got back to me with a "this is a known issue" (read BUG!).
Anyway, keep it simple to start with and that means using URIs
instead of relying on aliasing mechanisms that Orion or J2EE
provide.
Grant Doran Principle Architect
iLaunch inc. http://www.ilaunch.com/
-Original Message- From:
Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 31 January, 2001 12:24 AM To: Orion-Interest Subject: taglibs
Hi
I am trying hard to get started with tag libraries, but for
some reason I keep getting an empty "HTTP 500 Internal
server error" page when I call the JSP page which uses
my tag library - and the error is not explained in Orion's log files. I get the error when I try
to use my tags - not when I reference the library. I
feel confident that my reference to the taglib in my JSP is correct, because using a reference to an unexisting taglib results in
an error. But as soon as I call a tag from the library
i get the error - i.e. when writing something like
mytaglib:helloWorld.
Below is a thorough description of the situation - any
comments / thoughts would be appreciated.
R.
Here is my setup:
== the server === Orion 1.3.8 running on Windows 2000 Professional
== the tag == public class HelloWorldTag extends TagSupport {
public int
doEndTag() throws JspException {
try {
pageContext.getOut().write("The Tag says hello world!");
}
catch(java.io.IOException e) {
throw new
JspTagException("IO Error: " + e.getMessage());
}
return
EVAL_PAGE; } }
== web.xml ==
...
taglib
taglib-urijet/taglib-uri
taglib-location/WEB-INF/lib/taglib.jar/taglib-location
/taglib
...
== test.jsp = %@ taglib uri = "jet" prefix = "jet"
% p
jet:helloWorld /p
= taglib.tld taglib
tlibversion1.0/tlibversion
jspversion1.1/jspversion
shortnamejet/shortname
urihttp://www.orionserver.com/tutorials/mytags.jar/uri
infoMy
first Tag library/info
tag
namehelloWorld/name
tagclassdk.rockit.jet.HelloWorldTag/tagclass
bodycontentempty/bodycontent
infoA Hello
World tag/info
/tag
taglib.jar meta-inf/taglib.tld dk/rockit/jet/HelloWorldTag.class
Error deserializing EJB-session, anyone tell me why?
Dear All,
There are two errors in my appliction.log on Orion, I really don't know where i
miss,
can anyone tell me why? and how I do?
Think you a lot
yours Urey
** my errors *
01-1-31 3:35 galacyWeb: org.apache.struts.action.ActionServlet: Processing a GET for
/viewApplicationDetail
01-1-31 ÏÂÎç3:35 Error deserializing EJB-session
java.io.WriteAbortedException: Writing aborted by exception;
java.io.NotSerializableException:
com.mas.ebiz.asp.application.ejb.dao.ApplicationControlDAO
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:445)
at java.io.ObjectInputStream.inputClassFields(ObjectInputStream.java:2262)
at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:519)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1411)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at com.evermind.server.ejb.gt.ai2(JAX)
at com.evermind.server.ejb.EJBContainer.ai5(JAX)
at com.evermind.server.ejb.gv.f_(JAX)
at com.evermind.server.rmi.be.h5(JAX)
at com.evermind.server.rmi.RMIContext.gx(JAX)
at com.evermind.server.rmi.RMIContext.g_(JAX)
at com.evermind.server.rmi.RMIContext.lookup(JAX)
at com.evermind.server.hm.f4(JAX)
at com.evermind.server.hm.lookup(JAX)
at com.evermind.server.ejb.gv.f_(JAX)
at com.evermind.util.t.lookup(JAX)
at com.evermind.server.hm.f4(JAX)
at com.evermind.server.hm.lookup(JAX)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at
com.mas.ebiz.asp.application.util.EJBUtil.getApplicationServiceHome(EJBUtil.java:44)
at
com.mas.ebiz.asp.register.ViewApplicationDetailAction.perform(ViewApplicationDetailAction.java:44)
at
org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1492)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1360)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:441)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:190)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:302)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:329)
at com.evermind.server.http.d3.sw(JAX)
at com.evermind.server.http.d3.su(JAX)
at com.evermind.server.http.ef.s1(JAX)
at com.evermind.server.http.ef.do(JAX)
at com.evermind.util.f.run(JAX)
01-1-31 ÏÂÎç3:35 Error in bean ejb/applicationservice
java.rmi.RemoteException
at
com.mas.ebiz.asp.application.ejb.ApplicationServiceEJB.getApplicationDetail(ApplicationServiceEJB.java:113)
at
ApplicationService_StatefulSessionBeanWrapper3.getApplicationDetail(ApplicationService_StatefulSessionBeanWrapper3.java:262)
at
com.mas.ebiz.asp.register.ViewApplicationDetailAction.perform(ViewApplicationDetailAction.java:46)
at
org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1492)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1360)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:441)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:190)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:302)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:329)
at com.evermind.server.http.d3.sw(JAX)
at com.evermind.server.http.d3.su(JAX)
at com.evermind.server.http.ef.s1(JAX)
at com.evermind.server.http.ef.do(JAX)
at com.evermind.util.f.run(JAX)
01-1-31 3:39 galacyWeb: org.apache.struts.action.ActionServlet: Finalizing this
controller servlet
01-1-31 3:39 galacyWeb: 1.4.5 Stopped
** my code 1 *
public final class ViewApplicationDetailAction extends Action
{
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
try{
Locale locale = getLocale(request);
MessageResources messages = getResources();
HttpSession session = request.getSession();
String applicationId=request.getParameter("applicationId");
ApplicationServiceHome home=EJBUtil.getApplicationServiceHome();
ApplicationService remote = home.create();
ApplicationInfo info=remote.getApplicationDetail(applicationId);
session.putValue( "APPLICATON_INFO",info);
return(mapping.findForward("success"));
}catch(Exception e)
{
e.printStackTrace();
return(mapping.findForward("failure"));
}
}
}
** the code 2 *
public final class EJBUtil {
public static ApplicationEntityHome getApplicationEntityHome() throws
NamingException {
InitialContext initial = new InitialContext();
Object objref = initial.lookup(JNDINames.APPLICATIONENTITY_EJBHOME);
ApplicationEntityHome home = (ApplicationEntityHome)
PortableRemoteObject.narrow(objref, ApplicationEntityHome.class);
Re: Error deserializing EJB-session, anyone tell me why?
As far as I can judge it means that you need to implements java.io,Serializable interface in your com.mas.ebiz.asp.application.ejb.dao.ApplicationControlDAO class. Alexey Ryndin
Re: orion and mysql?
Hi, well, i'm more in need of some kind of step-by-step info as i'm new to java, j2ee and orion. So far i couldnt even setup orion to run plain servlets with mm.mysql as orion seems to ignore my classpath setting (or even i guess so). thanks - Original Message - From: "David Morton" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 6:24 PM Subject: Re: orion and mysql? I found it very easy...I use: http://mmmysql.sourceforge.net/ - jdbc driver http://javaexchange.com/ - connection pooling One variable i had was w/javaexchange's DBBroker, set AutoReconnect=true... so far so good...been using awhile David At 05:20 PM 1/30/01 +0100, you wrote: Hi, is there any simple how-to for setting up mysql with orion available? Or can someone explain me how to do it? thanks
RE: orion and mysql?
If somebody using Interbase successfully, please send your database schema and data-sources.xml part to this list. TIA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Randahl Fink Isaksen Sent: Wednesday, January 31, 2001 10:05 AM To: Orion-Interest Subject: RE: orion and mysql? Well then, is there a simple how-to for setting up Interbase with Orion? - Have you got a database schema which works? R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Arno Grbac Sent: 30. januar 2001 19:08 To: Orion-Interest Subject: RE: orion and mysql? This doesn't answer your question, but take a serious look at InterBase 6 (IT IS FREE AND OPEN SOURCE!!!). mySQL doesn't have a good locking mechanism yet, ..as well as some missing data types (last time I checked). Good luck, -arno -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marc Linke Sent: Tuesday, January 30, 2001 11:21 AM To: Orion-Interest Subject: orion and mysql? Hi, is there any simple how-to for setting up mysql with orion available? Or can someone explain me how to do it? thanks
RE: Which version is stable
I will not recommend you using IBM JVM. I myself tryed it and found it very instable and slow. Sun JVM solved both problems fine. (I've tried it on Win2k) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Rimmer Sent: Wednesday, January 31, 2001 8:07 AM To: Orion-Interest Subject: Re: Which version is stable The OOPS listing that Juan mentioned earlier is currently running v1.4.5. Granted it's just a bunch of JSPs but so far the server has crashed a few times. Note that I'm running IBM build cx130-2815 JVM. By the way, is there a new version of the IBM v1.3 JVM? I know releases are slipstreamed in. --- Jason Rimmer [EMAIL PROTECTED] - Original Message - From: "Korosh Afshar" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 9:10 PM Subject: RE: Which version is stable Just last week I deployed an EJB app that used CMP onto 1.4.5 with JDK 1.3. It was slow, slow, slow. I reverted back to 1.3.8 and it was fast. this is for Solaris 2.7. NT 1.3.8 was fast and consistent with 1.3.8 on solaris. k. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kemp Randy-W18971 Sent: Tuesday, January 30, 2001 9:24 AM To: Orion-Interest Subject: RE: Which version is stable At one point in time, they said the same thing of version 1.3.8. I believe what they mean is that the experimental version has now become the stable version. -Original Message- From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 6:14 AM To: Orion-Interest Subject: Which version is stable I am running Orion 1.3.8 seems to work, but I am thinking of upgrading. But which version should one upgrade to? - According to www.orionserver.com the new 1.4.5 is both stable and experimental... which sounds a bit like "stable and unstable". R.
Re: orion and mysql?
Really you should check out the J2EE specification at java.sun.com and in also grab some further info on JSP and servlets while you are there. Orion is suprisingly compatible with the J2EE spec. For example you should be using WAR deployment of your servlets then you will be able to use the standard classpath detailed in the Java Servlet specification. dan - Original Message - From: "Marc Linke" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 10:06 AM Subject: Re: orion and mysql? Hi, well, i'm more in need of some kind of step-by-step info as i'm new to java, j2ee and orion. So far i couldnt even setup orion to run plain servlets with mm.mysql as orion seems to ignore my classpath setting (or even i guess so). thanks - Original Message - From: "David Morton" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 6:24 PM Subject: Re: orion and mysql? I found it very easy...I use: http://mmmysql.sourceforge.net/ - jdbc driver http://javaexchange.com/ - connection pooling One variable i had was w/javaexchange's DBBroker, set AutoReconnect=true... so far so good...been using awhile David At 05:20 PM 1/30/01 +0100, you wrote: Hi, is there any simple how-to for setting up mysql with orion available? Or can someone explain me how to do it? thanks
RE: taglibs - Problem Solved
Title: RE: taglibs
Thank
you very much for your reply, Grant. As suggested I went back to the basics to
make sure my tags did work when I did not rely on the aliasing mechanisms. Doing
this I discovered a couple of minor syntactical errors and semantical errors,
which I fixed, and - voilla - suddently everything worked fine. Gradually I have
now moved all the tags into a library, and I am now back at the beginning - this
time with a system that works.
I am
looking forward to the next versions of Orion which, hopefully, will have some
more extensive debugging information - I think we really need
that.
Thanks
again for your input.
Randahl
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Grant
DoranSent: 30. januar 2001 23:56To:
Orion-InterestSubject: RE: taglibs
I had this problem early on. Go back
to basics to start with. Your first step is to refer
to the class directly and not through a jar file.
Try this:
1. Get rid of the taglib tag in the web.xml
2. Change the URI in the taglib.tld to:
uri/ 3. When using the TAGLLIB directive in
the JSP, refer to it using a relative or vitrual URL that you know is
correct. eg: %@ taglib
uri="/taglib/jet.tld" prefix="jet" %
This should work. One of the problems
that I've found is that using more elegant referencing to tags and
taglibraries is not portable. For instance, when I
tried to port our EAR file to Weblogic 6.0, I spent the best part of a day
trying to get the taglibrary to work even though the whole application runs
fine on Orion.
By the time I had written Weblogic off, their support people
finally got back to me with a "this is a known issue" (read BUG!).
Anyway, keep it simple to start with and that means using URIs
instead of relying on aliasing mechanisms that Orion or J2EE
provide.
Grant Doran Principle Architect
iLaunch inc. http://www.ilaunch.com/
-Original Message- From:
Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 31 January, 2001 12:24 AM To: Orion-Interest Subject: taglibs
Hi
I am trying hard to get started with tag libraries, but for
some reason I keep getting an empty "HTTP 500 Internal
server error" page when I call the JSP page which uses
my tag library - and the error is not explained in Orion's log files. I get the error when I try
to use my tags - not when I reference the library. I
feel confident that my reference to the taglib in my JSP is correct, because using a reference to an unexisting taglib results in
an error. But as soon as I call a tag from the library
i get the error - i.e. when writing something like
mytaglib:helloWorld.
Below is a thorough description of the situation - any
comments / thoughts would be appreciated.
R.
Here is my setup:
== the server === Orion 1.3.8 running on Windows 2000 Professional
== the tag == public class HelloWorldTag extends TagSupport {
public int
doEndTag() throws JspException {
try {
pageContext.getOut().write("The Tag says hello world!");
}
catch(java.io.IOException e) {
throw new
JspTagException("IO Error: " + e.getMessage());
}
return
EVAL_PAGE; } }
== web.xml ==
...
taglib
taglib-urijet/taglib-uri
taglib-location/WEB-INF/lib/taglib.jar/taglib-location
/taglib
...
== test.jsp = %@ taglib uri = "jet" prefix = "jet"
% p
jet:helloWorld /p
= taglib.tld taglib
tlibversion1.0/tlibversion
jspversion1.1/jspversion
shortnamejet/shortname
urihttp://www.orionserver.com/tutorials/mytags.jar/uri
infoMy
first Tag library/info
tag
namehelloWorld/name
tagclassdk.rockit.jet.HelloWorldTag/tagclass
bodycontentempty/bodycontent
infoA Hello
World tag/info
/tag
taglib.jar meta-inf/taglib.tld dk/rockit/jet/HelloWorldTag.class
Re: Session EJB Accessibility
ah, interesting subject. Heres another (database-centric) view: - dirty read (also referred to as "uncommitted read") means that one transaction can see changes another transaction has performed, but not yet committed. - optimistic concurrency means that a transaction, upon changing data, does not acquire an exclusive lock on the same. Instead, the lock is aquired at commit time, when also a check for conflicting changes is performed (based on data values or timestamps). The changes do not become visible to concurrent transactions before commit time. in that sense, dirty read and optimistic concurrency preclude eachother. In any case, "dirty read" refers to reading, OC to writing. - Original Message - From: "Dan Winfield" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 9:36 AM Subject: Re: Session EJB Accessibility I am sure a dirty read is when an object has an old set of values when compared to the database. This does happen in optimistic concurrency control. Dan - Original Message - From: "Vidur Dhanda" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 7:52 AM Subject: Re: Session EJB Accessibility I believe Orion uses pessimistic concurrency control. However, I don't think optimistic concurrency control would allow dirty reads -- I understand a dirty read to imply a transaction seeing the uncommitted state of another transaction. Vidur Jeff Schnitzer wrote: From: Gary Shea [mailto:[EMAIL PROTECTED]] I could use a little help here. My limited understanding of entity beans suggests that if I create an EB using a particular key value, as long as I refer only to that same key value there would only be one instance of the EB. Is that not true because of optimizations that allow bean pooling of a particular EB for a particular value of that EB's primary key if 'optimistic concurrency' is assumed? What _is_ 'optimistic concurrency' anyway, he said, exposing the full depth of his ignorance... This article is good explanation: http://theserverside.com/resources/news1.jsp#dev The details are spelled out in sections 9.6.9 and 9.6.10 of the EJB2.0 spec, but it's pretty esoteric. Basically: With pessimistic concurrency, the app server ensures that only a record is only represented by a single entity bean and serializes transactions on that bean. With optimistic concurrency, the app server allows a bean instance to be created for each transaction. This is much faster (no waiting for the other transaction to commit) but allows the possibility of dirty reads. It's analagous to isolation levels in the database. I'm not quite sure what Orion does, and I wish someone would chime in with a comment or two in this respect. I'm about to decompile the counter.jar example in hope of finding some clues. Jeff -- Vidur Dhanda Active Solutions tel: 617/566-1252 [EMAIL PROTECTED] www.active-solutions-inc.com
RE: Session EJB Accessibility
I just spent the last several hours reading everything I could possibly find about this topic, and I would like to retract my former explanation and issue a new one :-) Here's my current best guess as to how all this stuff works. I hope someone will correct any misconceptions. 1) Dirty reads don't happen in EJBland because for any given transaction, an entity will be loaded at most once. No matter what happens to the database, an entity bean involved in a transaction will work perfectly normally *at least* until commit time. 2) Finders might return different results in the same transaction, so the phantom read is still possible. 3) Commit Option C means that the state of an entity bean is ejbLoaded at the start of *every* transaction. Commit Option A means that entity bean state remains vaild between transactions (the bean is cached), so an ejbLoad is unnecessary for new transactions. Orion allows us to toggle which commit option is used with the "exclusive-write-access" attribute in orion-ejb-jar.xml. 4) Optimistic concurrency allows multiple transactions to simultaneously access a single entity. This is done by creating multiple entity bean instances, each of which load their state at the start of the transaction (ala Commit Option C). The bean instances can be modified independently. When each of the transactions are committed, the entity's old state is checked against the actual state in the database and if they differ, the transaction is aborted. This results in an exception that the client must handle (probably by redoing the transaction). Thus this concurrency model is "optimistic" because it expects that collisions will rarely occur. 5) Pessimistic concurrency means the app server serializes transactions which access an entity, guaranteeing that exceptions will never be thrown to the client because of the collision problem found in the optimistic model. Commit Option A is used, providing the performance advantage of eliminating the need for frequent ejbLoads, but the performance disadvantage of serialized transactions. 6) Pessimistic concurrency and Commit Option A start to seriously break down in a clustered environment because of the difficulty and performance cost of maintaining a single bean instance (or replicating its state). These are pure, wild speculation: 7) Orion uses pessimistic concurrency if exclusive-write-access is true, optimistic concurrency if exclusive-write-access is false. ? 8) If you cluster Orion, it uses optimistic concurrency. ? 9) If exclusive-write-access is false, and you externally modify the value of an entity in the database during a transaction which also modifies that value, Orion will throw an exception when you try to commit the transaction. ? I'm certain that at least in the simple case, Orion is using Commit Option A (and pessimistic concurrency) because a) I have observed that selects (ejbLoads) are not issued repeatedly to the JDBC driver and b) the decompiled counter.jar has no code for handling special error conditions. For general enlightenment purposes, this thread is especially good reading material: http://www.mail-archive.com/ejb-interest@java.sun.com/msg13276.html The slides for this conference session have a pretty fair discussion of isolation levels: http://jsp.java.sun.com/javaone/javaone2000/event.jsp?eventId=678 Jeff -Original Message- From: Dan Winfield [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 12:36 AM To: Orion-Interest Subject: Re: Session EJB Accessibility I am sure a dirty read is when an object has an old set of values when compared to the database. This does happen in optimistic concurrency control. Dan - Original Message - From: "Vidur Dhanda" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 7:52 AM Subject: Re: Session EJB Accessibility I believe Orion uses pessimistic concurrency control. However, I don't think optimistic concurrency control would allow dirty reads -- I understand a dirty read to imply a transaction seeing the uncommitted state of another transaction. Vidur Jeff Schnitzer wrote: From: Gary Shea [mailto:[EMAIL PROTECTED]] I could use a little help here. My limited understanding of entity beans suggests that if I create an EB using a particular key value, as long as I refer only to that same key value there would only be one instance of the EB. Is that not true because of optimizations that allow bean pooling of a particular EB for a particular value of that EB's primary key if 'optimistic concurrency' is assumed? What _is_ 'optimistic concurrency' anyway, he said, exposing the full depth of his ignorance... This article is good explanation: http://theserverside.com/resources/news1.jsp#dev The details are spelled out in sections 9.6.9 and 9.6.10 of the EJB2.0 spec, but it's pretty esoteric. Basically: With pessimistic concurrency, the app server ensures
RE: When using autonumber for the primarykey...
I must have misunderstood the question {:-). Working from a different frame
of reference, I guess. Good luck! :-)
-Original Message-
From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 11:17 AM
To: Orion-Interest
Subject: RE: When using autonumber for the primarykey...
but of course Krista, that would only work with BMP wouldn't it?
there's an article on orionsupport regarding counter.jar and how you can use
it to GENERATE unique id's
if you are required to use an IDENTITY field on the db, you're stuck with
BMP
JP
-Original Message-
From: Krista Richmond [mailto:[EMAIL PROTECTED]]
Sent: Martes, 30 de Enero de 2001 12:03
To: Orion-Interest
Subject: RE: When using autonumber for the primarykey...
If it's actually an autonumber field (at least with SQL Server), just insert
the rest of the fields (not including the autonumbered field), e.g.
(presuming your table includes First_Name,Last_Name, and an
autonumber...say, a Customer_ID field):
"INSERT INTO tblMyData(First_Name,Last_Name) VALUES('Sam','Adams')"
The table will automatically generate the autonumber for the ID field, hence
the name ;-). Additionally, if you *try* to insert a value into the
autonumber field, SQL Server will generate an error. I'm not sure whether
there may be different behaviors in different DBs...anyone?
HTH
-Original Message-
From: Øystein Walle [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 3:37 AM
To: Orion-Interest
Subject: When using autonumber for the primarykey...
I'm just wondering what to do when inserting into a table where the
primarykey has incremental int type?
Is this possible?
Please help.
Walle
Security...
Hi, just wondering in general about security and EJB. Say you want a secure transaction between two EBeans, do you have to code something in the EBean, set some properties for the EBean, or will it be Web Server (Orion) specific? Walle
RE: Developers
Just a few notes to this memo: 1. Someone on this list used openJMS (www.openjms.org) with Orion, and has good success, after they positioned some Jar files, etc. 2. As far as teaching students, I have learned on Orion and Jboss/Tomcat. Orion is free to developers and non commercial use, and Jboss/Tomcat is free (www.jboss.org). 3. Resin is good, if all you want is a JSP/servlet engine. If you want an EJB engine, then Resin will tell you how to hook up with popular EJB engines (both commercial and open source). 4. Large companies have the perception that the more you pay, the better the product. You do get some nice features with paying the big money: Nice front end tools, good documentation, and paid support. But from what people report in the lists (Orion, Jboss, Jonas), the support is not necessary superior to knowledgeable people answers questions via the list. 5. Apache and Tomcat are slated to use OpenEJB in the future (www.openejb.org). -Original Message- From: Jason Rimmer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 11:04 PM To: Orion-Interest Subject: Re: Developers Inline... - Original Message - From: "Burr Sutter" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 9:09 PM Subject: Re: Developers Thank You Juan, Ray and Randy I guess the initial question was a little vague but I like to hear people's opinions. After the download and simple install I was able to add a Sybase ASA database as a DataSource, connect to it via JSP and add a simple custom taglib to the default-web-app which proves to me that this thing at least works. My next tests include setting up my own web-app and playing around with EJB and JMS if I get the time. Overall it seems to be a good product. While the EJB implementation is quite nice the JMS implementation is lacking to say the least. Look in the archive for messages from me in this regard. I like how it picked up on the change I made to make the news.ear demo code function automatically. As I assume you know Allaire/JRun was purchased by Macromedia. Perhaps the marriage with Dreamweaver/UltraDev will payoff. I've never looked hard at JRun since most of my customers typically will pay the big bucks for a "brand-name" product like WebSphere, WebLogic or SilverStream but some want to keep the cost of licenses very low at times. I'm not sure about Resin at this time. It seems to ship with source code which is cool but it seems to be C code, not Java. The C code is the connector for Apache, etc. Resin's a Java product and the Java source is part of the distribution. I also teach Java and J2EE classes and we've been looking for an engine for student machines that is fairly easy to install and configure. Tomcat works for JSP but lacks the EJB, JNDI and JMS support needed. JNDI should be fine as well. JMS, well... SilverStream 3.7 has been certified for J2EE and it seems to be very solid. I spent several days with about 20 other people putting it through some exercises. Weblogic is great but has to be restarted a lot to make some code changes (5.1). This has lessened greatly with v6.0 but of course it's in BETA and only for Win32 and Solaris. WebSphere doesn't seem to fully understand the proper directory structure of a web-app and the use of WARs completely and it is VERY slow on my NT box to startup and build/deploy simple JSPs. WebSphere's a glorified servlet engine. For really exercising J2EE I'd stay away. Any need to restart Orion after a change to: JSP EJB JMS queue or topic Bean for a JSP Taglib classes, .tld, .xml .war, .ear, .jar? I don't really remember but the startup time for Orion is so small it's not that big a deal (at least for instruction). Startup time's nothing like WebLogic that's for sure. Thanks, Burr [EMAIL PROTECTED] snip --- Jason Rimmer [EMAIL PROTECTED]
RE: Feedback on using Orion in Production.
Currently, Orion is being reorganized under another company, in order to provide enhanced support (at a higher price). There are plans to keep developer and non commercial licenses free, and hold the basic price at $1500. I understand those support plans are going slower then usual, and everyone on this list is looking for the final support plans to materialize. As far as other issues on this list, I will let others share in the response. -Original Message- From: Korosh Afshar [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 6:05 PM To: Orion-Interest Subject: Feedback on using Orion in Production. Hi list, I know this question has been asked before and I have seen very little response that would eliviate the anexiety I have in going full speed ahead with Orion for our production deployments. I have also looked at and solicited comments from the web site URL's posted on orionserver.com as the customers using Orion. I have not received any response from these companies concerning their experience with Orion. Please provide any feedback you have on: -how does orion perform in any production environment you have. -how many client users for the above. -how is the phone support for purchased licenses. -how is the email support from [EMAIL PROTECTED] -how well does clustering work with orion. Please provide ANY comments you have. I would realy really appreciate knowing of your experience. I have used it for one test deployment of an EJB application and I like the no-frill down to grind feeling I get from it but I had some bad experience last week when soliciting support from [EMAIL PROTECTED] for slow peforming 1.4.5 version. I finally reverted back to 1.3.8 which eliminated that problem. I had no response from support however. I am now a bit scared to suggest to management to use in production due to that experience so decided to get more information from the mailing list on the weaknesses of the product and quality of support people get.
server goes down after upgrade from 1.3.8 to 1.4.5
Hi, We upgraded orion server from 1.3.8 to 1.4.5. Now server goes down once you exit from window. Server is running on SunOS 5.7. I start server using java -jar orion.jar with 1.3.8, server was running even after log off. Please help!! thanks, Nilesh
RE: Developers
One thing I forgot to mention, is that Jboss/Tomcat (www.jboss.org) are pre-configured, and run right from the box. Either Orion (www.orionserver.org) or Jboss/Tomcat would be nice for student needs. -Original Message- From: Jason Rimmer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 11:04 PM To: Orion-Interest Subject: Re: Developers Inline... - Original Message - From: "Burr Sutter" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 9:09 PM Subject: Re: Developers Thank You Juan, Ray and Randy I guess the initial question was a little vague but I like to hear people's opinions. After the download and simple install I was able to add a Sybase ASA database as a DataSource, connect to it via JSP and add a simple custom taglib to the default-web-app which proves to me that this thing at least works. My next tests include setting up my own web-app and playing around with EJB and JMS if I get the time. Overall it seems to be a good product. While the EJB implementation is quite nice the JMS implementation is lacking to say the least. Look in the archive for messages from me in this regard. I like how it picked up on the change I made to make the news.ear demo code function automatically. As I assume you know Allaire/JRun was purchased by Macromedia. Perhaps the marriage with Dreamweaver/UltraDev will payoff. I've never looked hard at JRun since most of my customers typically will pay the big bucks for a "brand-name" product like WebSphere, WebLogic or SilverStream but some want to keep the cost of licenses very low at times. I'm not sure about Resin at this time. It seems to ship with source code which is cool but it seems to be C code, not Java. The C code is the connector for Apache, etc. Resin's a Java product and the Java source is part of the distribution. I also teach Java and J2EE classes and we've been looking for an engine for student machines that is fairly easy to install and configure. Tomcat works for JSP but lacks the EJB, JNDI and JMS support needed. JNDI should be fine as well. JMS, well... SilverStream 3.7 has been certified for J2EE and it seems to be very solid. I spent several days with about 20 other people putting it through some exercises. Weblogic is great but has to be restarted a lot to make some code changes (5.1). This has lessened greatly with v6.0 but of course it's in BETA and only for Win32 and Solaris. WebSphere doesn't seem to fully understand the proper directory structure of a web-app and the use of WARs completely and it is VERY slow on my NT box to startup and build/deploy simple JSPs. WebSphere's a glorified servlet engine. For really exercising J2EE I'd stay away. Any need to restart Orion after a change to: JSP EJB JMS queue or topic Bean for a JSP Taglib classes, .tld, .xml .war, .ear, .jar? I don't really remember but the startup time for Orion is so small it's not that big a deal (at least for instruction). Startup time's nothing like WebLogic that's for sure. Thanks, Burr [EMAIL PROTECTED] snip --- Jason Rimmer [EMAIL PROTECTED]
Re: R: R: frustrated - jdbc: No suitable driver
Hey Tom,
Potentially silly question (somewhat new to Orion but I've used a few other
app. servers). Are you basically saying that the use of a
javax.sql.DataSource acquried via a call to InitialContext.lookup() means I
don't need a JDBC Driver on a remote client machine (end-user's desktop)?
I was unaware that this trick would work. I've always tried to push all
database access to session beans, servlets or server-RMI objects.
Thanks,
Burr
[EMAIL PROTECTED]
- Original Message -
From: Tom Mitchell [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Tuesday, January 30, 2001 9:28 PM
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Jeff,
I disagree. Part of the benefit of a DataSource is that it can abstract
the actual driver or database being used. If I can ask a DataSource for
a database connection and not have to care about which client-side
driver to load, and (less practically), even what rdbms i am using.
That way, the app server can change databases, drivers, even vendors
without its clients being aware.
I experienced this issue porting an app from WebLogic. I used the same
schema and sql with SQL Server and Postgres on WebLogic. My client
application (which both queried and populated the database) never
changed. It just got a Context from the app server, gfot a DataSource
by name, then got plain old JDBC Connections from there. No JDBC
drivers at all.
I think that is a useful layer.
PS: I have unsubscribed from the list - if you would like to continue
the discussion, please reply to my personal address.
Thanks for your thoughts.
I appreciate your point of view, I just disagree with it.
Jeff Schnitzer wrote:
If the client is going to use the JDBC driver, it must be able to load
the class(es). This means you need to package the driver with the
client application. I'm puzzled by your comments about clients not
needing to care about drivers - are these classes just going to
materialize out of thin air? I suppose in theory the server could do
something with http classloading, but why bother with the extra
complexity, security considerations, and licensing issues? You know
you're going to need the classes anyways, package them with the client.
Jeff
-Original Message-
From: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 9:08 AM
To: Orion-Interest
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Again, thanks for your replies.
What is curious to me is that the driver performs fine within a jsp. I
look up loc with no problem.
It only has a problem from a client application. And, it does not seem
like a client to a DataSource should ever have to care about drivers -
that is the container's job in my opinion.
data-source
class="com.evermind.sql.ConnectionDataSource"
name="SomeDatasource"
location="loc"
xa-location="jdbc/xa/SomeXADS"
ejb-location="ejb/weather"
schema="database-schemas/postgresql.xml"
connection-driver="org.postgresql.Driver"
username="tom"
password="tR16/4"
url="jdbc:postgresql://192.168.1.5:5432/weather"
inactivity-timeout="30"
/
Any more ideas?
DeVincentiis Giustino wrote:
Sorry, the message "No suitable driver" probably means a
problem with jdbc
driver.
So if you have into the data-sources.xml the definition:
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="Hypersonic"
location="jdbc/HypersonicCoreDS"
xa-location="jdbc/xa/HypersonicXADS"
ejb-location="jdbc/HypersonicDS"
connection-driver="org.hsql.jdbcDriver"
username="sa"
password=""
url="jdbc:HypersonicSQL:./database/defaultdb"
inactivity-timeout="30"
/
you should lookup "jdbc/HypersonicDS", and you should have the driver
classes in your /orion/lib directory.
Giustino
-Messaggio originale-
Da: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Inviato: marted 30 gennaio 2001 12.24
A: Orion-Interest
Oggetto: Re: R: frustrated - jdbc: No suitable driver
Thanks for the reply. That is exactly how I am initializing
the context
in my client application:
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.ApplicationClientInitialContextFactory");
ht.put(Context.PROVIDER_URL, "ormi://192.168.1.3");
ht.put(Context.SECURITY_PRINCIPAL, "someUser");
ht.put(Context.SECURITY_CREDENTIALS, "secret");
// Obtain connection
InitialContext ctx = new InitialContext(ht);
DeVincentiis Giustino wrote:
Try initializing the context this way:
...
Properties props = new Properties();
props.setProperty("java.naming.factory.initial","com.evermind.s
erver.Applica
Re: App that runs on OrionServer but throws a java.lang.VerifyError on weblogic 6.0
I am just guessing here, since I don't use weblogic. It may be possible that web logic forces only RMI-IIOP arguements. In which case any thing passed on the wire must be a primitive, Serializable or Remote type. If they are not, they are invalid ant may fail on deployment when weblogic verifies your beans and such. I don't believe that orion forces RMI-IIOP. See javasoft for more info about RMI-IIOP. M Ismael Blesa Part wrote: What does (Is your agruement RMI-IIOP valid) mean?, this class is used from a javabean used from a JSP. Its parameters are two classes from my own and java.lang.String from Sun. We are not using neither clustering neither persistant sessions (at least I think that this is the default configuration) Something that shock me is that it runs fine under Orion, then what could be happening? Matt Bauer wrote: Is your agruement RMI-IIOP valid? M Ismael Blesa Part wrote: We have developed a web application that works fine under OrionServer. It has JSP, JavaBeans and Taglibs. Now we are testing with Bea Weblogic and there are some strange errors thrown by the server. It complains about (java.lang.VerifyError: (class: com/test/logic/integration/connectors/BeanConnector, method: connect signature: com/test/logic/MyData;Lcom/test/logic/Environment;Ljava/lang/String;)V) Incompatible object argument for function call) It is a very strange error, I have compiled all my code with javac (1.3.0_01) and also with jikes last version. I have changed also bea weblogic to point jdk to my installed jdk. The best of all this strange error is that this method is not called. ie: looking on the print messages I have put on the code, execution stops before the invocation of this method. I think that this error comes when the java virtual machine tries to load this class. Anybody has any idea about what is causing this error to appear? Regards, Ismael ([EMAIL PROTECTED])
Re: App that runs on OrionServer but throws a java.lang.VerifyError on weblogic 6.0
The BEA support channels would seem to be a better place to ask this question. Would you ask a Win2K question on a linux support list? Kirk Yarina At 05:21 PM 1/30/01 +0100, you wrote: We have developed a web application that works fine under OrionServer. It has JSP, JavaBeans and Taglibs. Now we are testing with Bea Weblogic and there are some strange errors thrown by the server. It complains about (java.lang.VerifyError: (class: com/test/logic/integration/connectors/BeanConnector, method: connect signature: com/test/logic/MyData;Lcom/test/logic/Environment;Ljava/lang/String;)V) Incompatible object argument for function call) It is a very strange error, I have compiled all my code with javac (1.3.0_01) and also with jikes last version. I have changed also bea weblogic to point jdk to my installed jdk. The best of all this strange error is that this method is not called. ie: looking on the print messages I have put on the code, execution stops before the invocation of this method. I think that this error comes when the java virtual machine tries to load this class. Anybody has any idea about what is causing this error to appear? Regards, Ismael ([EMAIL PROTECTED])
SV: R: R: frustrated - jdbc: No suitable driver
You will have to define the jdbc connection in the datasource configuration
file on the appserver though.
The client should never use any jdbc directly :)
The Entity beans can be mapped using cmp or bmp and the lookup through the
JNDI context for the suitable connection instance is
done through the J2EE context classes as explained by Burr..
A normal method to do this is (inside an EJB in this example):
Connection conn = null;
try {
InitialContext ic = new InitialContext();
/* Here is the JNDI name...check orions data-sources.xml
* file in the config directory to see examples with hsql
*/And note that you should prolly choose to use the pooled-location
name
DataSource ds (DataSource)ic.lookup("jdbc/ProdObjectSpacePooledDS");
conn = ds.getConnection();
} catch (Exception ex) {
throw new EJBException(ex);
}
// .. do some JDBC stuff
conn.close();
Hope this helps you further :=)
Have fun!!
Klaus Myrseth
-Opprinnelig melding-
Fra: Burr Sutter [mailto:[EMAIL PROTECTED]]
Sendt: 31. januar 2001 15:21
Til: Orion-Interest
Emne: Re: R: R: frustrated - jdbc: No suitable driver
Hey Tom,
Potentially silly question (somewhat new to Orion but I've used a few other
app. servers). Are you basically saying that the use of a
javax.sql.DataSource acquried via a call to InitialContext.lookup() means I
don't need a JDBC Driver on a remote client machine (end-user's desktop)?
I was unaware that this trick would work. I've always tried to push all
database access to session beans, servlets or server-RMI objects.
Thanks,
Burr
[EMAIL PROTECTED]
- Original Message -
From: Tom Mitchell [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Tuesday, January 30, 2001 9:28 PM
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Jeff,
I disagree. Part of the benefit of a DataSource is that it can abstract
the actual driver or database being used. If I can ask a DataSource for
a database connection and not have to care about which client-side
driver to load, and (less practically), even what rdbms i am using.
That way, the app server can change databases, drivers, even vendors
without its clients being aware.
I experienced this issue porting an app from WebLogic. I used the same
schema and sql with SQL Server and Postgres on WebLogic. My client
application (which both queried and populated the database) never
changed. It just got a Context from the app server, gfot a DataSource
by name, then got plain old JDBC Connections from there. No JDBC
drivers at all.
I think that is a useful layer.
PS: I have unsubscribed from the list - if you would like to continue
the discussion, please reply to my personal address.
Thanks for your thoughts.
I appreciate your point of view, I just disagree with it.
Jeff Schnitzer wrote:
If the client is going to use the JDBC driver, it must be able to load
the class(es). This means you need to package the driver with the
client application. I'm puzzled by your comments about clients not
needing to care about drivers - are these classes just going to
materialize out of thin air? I suppose in theory the server could do
something with http classloading, but why bother with the extra
complexity, security considerations, and licensing issues? You know
you're going to need the classes anyways, package them with the client.
Jeff
-Original Message-
From: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 9:08 AM
To: Orion-Interest
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Again, thanks for your replies.
What is curious to me is that the driver performs fine within a jsp. I
look up loc with no problem.
It only has a problem from a client application. And, it does not seem
like a client to a DataSource should ever have to care about drivers -
that is the container's job in my opinion.
data-source
class="com.evermind.sql.ConnectionDataSource"
name="SomeDatasource"
location="loc"
xa-location="jdbc/xa/SomeXADS"
ejb-location="ejb/weather"
schema="database-schemas/postgresql.xml"
connection-driver="org.postgresql.Driver"
username="tom"
password="tR16/4"
url="jdbc:postgresql://192.168.1.5:5432/weather"
inactivity-timeout="30"
/
Any more ideas?
DeVincentiis Giustino wrote:
Sorry, the message "No suitable driver" probably means a
problem with jdbc
driver.
So if you have into the data-sources.xml the definition:
data-source
class="com.evermind.sql.DriverManagerDataSource"
name="Hypersonic"
location="jdbc/HypersonicCoreDS"
xa-location="jdbc/xa/HypersonicXADS"
ejb-location="jdbc/HypersonicDS"
connection-driver="org.hsql.jdbcDriver"
username="sa"
Student use and licenses
I will share these thoughts on student use, since it was brought up. I think that you can use a combination of open source and commercial products for student use, without paying the required fees (as long as the student applications are not deployed on the server for commercial use). Here are some combinations I would suggest, to use servlets, JSP and EJB: 1. Orion by itself (www.orionserver.com). 2. Jboss/Tomcat (pre-configured at www.jboss.org). 3. Resin and Jonas (www.caucho.org and www.evidian.com/jonas).
SV: R: R: frustrated - jdbc: No suitable driver
Ofcourse if you use this in an Entity bean pls use the EJB connection :)
Sorry just aditional information - forgot this on the first letter :)
Klaus
-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sendt: 31. januar 2001 16:19
Til: Orion-Interest
Emne: SV: R: R: frustrated - jdbc: No suitable driver
You will have to define the jdbc connection in the datasource configuration
file on the appserver though.
The client should never use any jdbc directly :)
The Entity beans can be mapped using cmp or bmp and the lookup through the
JNDI context for the suitable connection instance is
done through the J2EE context classes as explained by Burr..
A normal method to do this is (inside an EJB in this example):
Connection conn = null;
try {
InitialContext ic = new InitialContext();
/* Here is the JNDI name...check orions data-sources.xml
* file in the config directory to see examples with hsql
*/And note that you should prolly choose to use the pooled-location
name
DataSource ds (DataSource)ic.lookup("jdbc/ProdObjectSpacePooledDS");
conn = ds.getConnection();
} catch (Exception ex) {
throw new EJBException(ex);
}
// .. do some JDBC stuff
conn.close();
Hope this helps you further :=)
Have fun!!
Klaus Myrseth
-Opprinnelig melding-
Fra: Burr Sutter [mailto:[EMAIL PROTECTED]]
Sendt: 31. januar 2001 15:21
Til: Orion-Interest
Emne: Re: R: R: frustrated - jdbc: No suitable driver
Hey Tom,
Potentially silly question (somewhat new to Orion but I've used a few other
app. servers). Are you basically saying that the use of a
javax.sql.DataSource acquried via a call to InitialContext.lookup() means I
don't need a JDBC Driver on a remote client machine (end-user's desktop)?
I was unaware that this trick would work. I've always tried to push all
database access to session beans, servlets or server-RMI objects.
Thanks,
Burr
[EMAIL PROTECTED]
- Original Message -
From: Tom Mitchell [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Tuesday, January 30, 2001 9:28 PM
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Jeff,
I disagree. Part of the benefit of a DataSource is that it can abstract
the actual driver or database being used. If I can ask a DataSource for
a database connection and not have to care about which client-side
driver to load, and (less practically), even what rdbms i am using.
That way, the app server can change databases, drivers, even vendors
without its clients being aware.
I experienced this issue porting an app from WebLogic. I used the same
schema and sql with SQL Server and Postgres on WebLogic. My client
application (which both queried and populated the database) never
changed. It just got a Context from the app server, gfot a DataSource
by name, then got plain old JDBC Connections from there. No JDBC
drivers at all.
I think that is a useful layer.
PS: I have unsubscribed from the list - if you would like to continue
the discussion, please reply to my personal address.
Thanks for your thoughts.
I appreciate your point of view, I just disagree with it.
Jeff Schnitzer wrote:
If the client is going to use the JDBC driver, it must be able to load
the class(es). This means you need to package the driver with the
client application. I'm puzzled by your comments about clients not
needing to care about drivers - are these classes just going to
materialize out of thin air? I suppose in theory the server could do
something with http classloading, but why bother with the extra
complexity, security considerations, and licensing issues? You know
you're going to need the classes anyways, package them with the client.
Jeff
-Original Message-
From: Tom Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 30, 2001 9:08 AM
To: Orion-Interest
Subject: Re: R: R: frustrated - jdbc: No suitable driver
Again, thanks for your replies.
What is curious to me is that the driver performs fine within a jsp. I
look up loc with no problem.
It only has a problem from a client application. And, it does not seem
like a client to a DataSource should ever have to care about drivers -
that is the container's job in my opinion.
data-source
class="com.evermind.sql.ConnectionDataSource"
name="SomeDatasource"
location="loc"
xa-location="jdbc/xa/SomeXADS"
ejb-location="ejb/weather"
schema="database-schemas/postgresql.xml"
connection-driver="org.postgresql.Driver"
username="tom"
password="tR16/4"
url="jdbc:postgresql://192.168.1.5:5432/weather"
inactivity-timeout="30"
/
Any more ideas?
DeVincentiis Giustino wrote:
Sorry, the message "No suitable driver" probably means a
problem with jdbc
driver.
So if you have into the data-sources.xml the definition:
data-source
Re: server goes down after upgrade from 1.3.8 to 1.4.5
Try nohup java -jar orion.jar Kirk Yarina At 09:11 AM 1/31/01 -0500, you wrote: Hi, We upgraded orion server from 1.3.8 to 1.4.5. Now server goes down once you exit from window. Server is running on SunOS 5.7. I start server using java -jar orion.jar with 1.3.8, server was running even after log off. Please help!! thanks, Nilesh
Re: server goes down after upgrade from 1.3.8 to 1.4.5
If you dont specify nohup then your process is attached to your terminal. You should use nohup java -jar orion.jar Nilesh Patel wrote: Hi, We upgraded orion server from 1.3.8 to 1.4.5. Now server goes down once you exit from window. Server is running on SunOS 5.7. I start server using java -jar orion.jar with 1.3.8, server was running even after log off. Please help!! thanks, Nilesh
RE: Session EJB Accessibility
It's tough for container providers to provide Singleton behavior when more than one JVM is involved; I can trace this back to CORBA. That's why it's not in the spec. JP -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Martes, 30 de Enero de 2001 20:29 To: Orion-Interest Subject: RE: Session EJB Accessibility I'm confused by your comments; does it need to manage state, or doesn't it? I'm assuming it does, otherwise you would just use a stateless session bean. Here's some fodder for conversation: I don't think there is an EJB facility which will help you. SLSBs are pooled and can timeout, SFSBs have no lookup mechanism, can timeout, and aren't reentrant (although Orion, despite the spec, serializes calls, which is good), and entity beans will get all wacky because of the multiple instances you will get from an optimistic concurrency model. It seems like what you want is either a SLSB which never times out and is guaranteed to only have one instance in the pool, or a BMP entity bean with a guarantee of serialized transactions. Is it possible to make Orion do either of these? And what would happen in a clustered solution? I propose that the only server-independent way to do what you want is to use an RMI server. The EJB specification really needs a "SingletonBean", preferrably one which allows concurrent calls (and thus reasonable performance). Comments? Jeff -Original Message- From: Mark Bernardinis [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 12:18 AM To: Orion-Interest Subject: Re: Session EJB Accessibility I don't want to do any database activity. I just want this Java Object to be accessible as an EJB accessible by many different clients hosted by an Application Server. The object doesn't have to be stateful either. It sounds like you're describing an entity bean more than a session bean. An entity bean can be called by many clients although access is serialized. And certainly the role of an entity bean is to encapsulate data in a apparently-storage-mechanism-independent manner, from the client's perspective... How does the notion of a session play into what you want the bean to do? Gary Mark Bernardinis ([EMAIL PROTECTED]) wrote: Requirements: An EJB to be Stateful Accessible by more than client Share the same data object and information Summarising the above information, I would like to have an EJB that can be called by many clients yet share the same underlying data within the bean. These clients may be another application running under Orion or a stand-alone application. Is this possible, and if it is, what special requirements do I need to meet. I have looked at SessionContext but does this have anything to do with it? Thanks in advance. Mark
Re: EJB's referenced from a servlet?
Don't worry about it - I found the error of my ways. Emil Sarkissian wrote: Hi, I seem to not be able to look up an EJB from my servlet. Anyone have any ideas how you make your EJBs accessible to servlets? The error I get is "MyCart not found". Thanks, Emil.
Re: App that runs on OrionServer but throws ajava.lang.VerifyError on weblogic 6.0
I think that this question is not a question that should not be posted in this maillist. Here there is a lot of people that has experience on j2ee programming and use OrionServer for developing J2EE applications but later they have to port their application to another J2EE application server, because OrionServer is not known and customer wants known ( but not necessary better ) application servers like Bea, Websphere, .etc. Then if you do not want to see any mail with subject like this one you are free to ignore it. I have written a very explanatory subjet to avoid that people that is not interested on this subject to open it. When I have the solution I will post it on the mail list to let other people to avoid this error take it or leave it . If you want other type of aclaration feel free to send me a private email KirkYarina wrote: The BEA support channels would seem to be a better place to ask this question. Would you ask a Win2K question on a linux support list? Kirk Yarina At 05:21 PM 1/30/01 +0100, you wrote: We have developed a web application that works fine under OrionServer. It has JSP, JavaBeans and Taglibs. Now we are testing with Bea Weblogic and there are some strange errors thrown by the server. It complains about (java.lang.VerifyError: (class: com/test/logic/integration/connectors/BeanConnector, method: connect signature: com/test/logic/MyData;Lcom/test/logic/Environment;Ljava/lang/String;)V) Incompatible object argument for function call) It is a very strange error, I have compiled all my code with javac (1.3.0_01) and also with jikes last version. I have changed also bea weblogic to point jdk to my installed jdk. The best of all this strange error is that this method is not called. ie: looking on the print messages I have put on the code, execution stops before the invocation of this method. I think that this error comes when the java virtual machine tries to load this class. Anybody has any idea about what is causing this error to appear? Regards, Ismael ([EMAIL PROTECTED])
RE: When using autonumber for the primarykey...
I'm using the counter.jar which is fine, but does it have any impact on performance ? Ok, the EJB spec doesn't support id fields, but surely now for every create() I'm actually doing twice the work - ie: creating and loading the counter entity bean and the entity bean using the counter? That can't be right ...
JSP TagLibs and UTF8 Encoding
I'm having an issue where a custom JSP BodyTag used in JSP Pages is producing some undesirable results. I am hoping someone out there has already encountered a similar problem and can point me in the right direction in solving mine. The issue is that my custom JSP BodyTag is a wrapper around JSP Code producing UTF8 Encoded XML Content. Portions of this content is encoded in UTF8 because they are language resources and this is the only way they can be represented (e.g. and ? ). My JSP Body Tag Implementation takes the produced XML Content and processes it against an XSL Style Sheet to produce the desired display content. However, the UTF8 Characters are being munged and not displayed correctly. The crux of the matter is how do I maintain the encoding of the produced XML between the page being processed and handing it of to the XSL Parser for transformation. Currently I am trying to use something of the nature: StringReader xmlReader = new StringReader(bodyContent.getString().trim()); InputSource xmlInputSource = new InputSource(xmlReader); where the bodyContent is the standard internal JSP Tag extension member variable. I then used the created InputSource for any XML operations, but my content still has munged UTF8 characters. Anyone have any suggestions? Thanks Greatly, Ted --- Ted Rice APAMA Ltd, 17 Millers Yard, Mill Lane Cambridge CB2 1RQ, United Kingdom Email: [EMAIL PROTECTED] Mobile: +44 (0)7899 876489 Phone: +44 (0)1223 257973 [Histon Office] Fax:+44 (0)1223 518859
Problem with latest Oracle JDBC.zip..anyone having similar problems?
Hi there, We just moved to Oracle 8.1.7 database (or upgraded to it). The new jdbc.zip that is required to use it is causing some odd problems with Orion 1.3.8 that we are running. Specifically, it appears every time we try to connect to the database it gives a "Stream already closed" error. Is anyone experiencing similar problems? Will the 1.4.5 version of Orion fix this? We tried removing the jdbc.jar in the orion folder, and we are only using Orion for jsp/servlet engine (not yet done any EJB work). Thanks.
Native User Support
Howdy, Does anybody know where I can find the native user support archive (I'm really after the redhat-6.2/liborion.so) that is linked from the http://www.orionsupport.com/articles/users.html page with the URL http://www.orionserver.com/private/native_user_support.tar.gz? I'm getting a 404 - File Not Found error. Thanks! -Ken Wingerden
Re: server goes down after upgrade from 1.3.8 to 1.4.5
Hi, Thanks for replies. Actually I forgot to mention in my previous emails about nohup. I also tried nohup java -jar orion.jar . But it still terminates after I logoff. TIA Nilesh - Original Message - From: "Ismael Blesa Part" [EMAIL PROTECTED] Date: Wednesday, January 31, 2001 11:23 am Subject: Re: server goes down after upgrade from 1.3.8 to 1.4.5 If you dont specify nohup then your process is attached to your terminal. You should use nohup java -jar orion.jar Nilesh Patel wrote: Hi, We upgraded orion server from 1.3.8 to 1.4.5. Now server goes down once you exit from window. Server is running on SunOS 5.7. I start server using java -jar orion.jar with 1.3.8, server was running even after log off. Please help!! thanks, Nilesh
Re: server goes down after upgrade from 1.3.8 to 1.4.5
A guess from me is that when executing nohup java -jar orion.jar stdout goes to console. If the console quits maybe an IOException occurs which will terminate orion. It is a guess. try redirect it orion.jar 1errorlog.txt 2stdout.txt forgot the correct way to write it, but it is something like that. Or you can try running with a config file where you have specified outstreams. regards Johan Fredriksson - Original Message - From: "Nilesh Patel" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, January 31, 2001 9:34 PM Subject: Re: server goes down after upgrade from 1.3.8 to 1.4.5 Hi, Thanks for replies. Actually I forgot to mention in my previous emails about nohup. I also tried nohup java -jar orion.jar . But it still terminates after I logoff. TIA Nilesh - Original Message - From: "Ismael Blesa Part" [EMAIL PROTECTED] Date: Wednesday, January 31, 2001 11:23 am Subject: Re: server goes down after upgrade from 1.3.8 to 1.4.5 If you dont specify nohup then your process is attached to your terminal. You should use nohup java -jar orion.jar Nilesh Patel wrote: Hi, We upgraded orion server from 1.3.8 to 1.4.5. Now server goes down once you exit from window. Server is running on SunOS 5.7. I start server using java -jar orion.jar with 1.3.8, server was running even after log off. Please help!! thanks, Nilesh
Re: Servlet loading twice if init() not finished?
First of all your orion startup servlet only needs the service method.
And then it should be load-on-startup x /load-on-startup ( see web.xml)
where x is an appropiate nr.
This will force orion to load it before it is fully inited.
regards
Johan
( my servlet that loads up data from database takes between 15 sek - 240 sek
depending on the connection and I never had any problems with two
instances...)
- Original Message -
From: "Marco Isella" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Wednesday, January 31, 2001 10:40 PM
Subject: Servlet loading twice if init() not finished?
Hi,
i have a servlet as a front component in my webapp; the servlet has also
the
task of loading objects from a db during his inizialization. Loading the
objects takes some time i have encountered a situation wich i didn't
expected wich i'm not sure if i'm doing something wrong or it is orion.
The situation is that if orion recive a request wich point to the servlet
before the servlet has finished the init() method (wich was triggered from
a
previous request) it creates another instance of the servlet.
I have done a small example so that i can explain me in a more clear way :
in my web.xml file i have defined mapped the servlet:
servlet
servlet-nametestServlet/servlet-name
servlet-classTestServlet/servlet-class
/servlet
servlet-mapping
servlet-nametestServlet/servlet-name
url-pattern/test/url-pattern
/servlet-mapping
the code of the servlet is:
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class TestServlet extends HttpServlet {
public void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
doGet(req, res);
}
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
System.out.println("doGet()");
}
public void init() {
System.out.println("init() " +this);
try {
Thread.currentThread().sleep(5000);// this is for
simulating
the time consuming task
} catch (Exception e) {}
System.out.println("done! " + this);
}
}
now, if I start the server i call the servlet 2 times (the second before
init() finish) i can see 2 servlet instance created (see the output below)
D:\orionjava -jar d:/orion/orion.jar
Orion/1.4.5 initialized
init() TestServlet@704baa
init() TestServlet@34fad5
done! TestServlet@704baa
doGet()
done! TestServlet@34fad5
doGet()
wich is not really what i want( expected). I haven't watched the specs so
i'm not sure if this is the correct behavior in a situation like that i
would like to know what u people think about it.
If someone has also a workaround it will be very much appreciated.. ;)
I'm running orion on w2k (i tried 1.4.5 1.4.4, same behaviour for both).
Marco
--
Ing. Marco Isella, Software Engineer
TINET SA, Via Violino 1, CH-6928 Manno-Lugano
tel. +41 91 612 22 22, fax. +41 91 612 22 23
email [EMAIL PROTECTED]
http://www.tinet.com
