SV: user manager, principals shutdown
Did you remove the permission for rmi:login? By default this goes something like: group name=users descriptionusers/description permission name=rmi:login / /group (the default administrator is also part of users) or did you remove the permission for administrator to administrate? By defaut this goes something like: group name=administrators descriptionadministrators/description permission name=administration / /group or you delete your settings for namespace access in your orion-application.xml? It goes something like: namespace-access read-access namespace-resource root= security-role-mapping name=lt;jndi-user-rolegt; group name=administrators / /security-role-mapping /namespace-resource /read-access write-access namespace-resource root= security-role-mapping name=lt;jndi-user-rolegt; group name=administrators / /security-role-mapping /namespace-resource /write-access /namespace-access Hope this helps, WR Magnus Rydin IronFlare AB -Ursprungligt meddelande- Fran: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]For Tim Courtney Skickat: den 9 januari 2002 04:09 Till: Orion-Interest Amne: user manager, principals shutdown I need some help fixing something I broke. I stepped through the user manager tutorial on orionsupport ( http://uk.orionsupport.com/articles/usermanager.html ) and managed to put BASIC authentication on a certain directory on my site. But since then, it seems I deleted the information that allows the shutdown command java -jar admin.jar ormi://localhost admin x -shutdown this command looks up the username/password in the custom UserManager and always returns Security error: Invalid username/password for default (admin) I would prefer that the server admin the users in the custom UserManager be kept separate. is my principals.xml meant to have two different groups? can the server admin user remain in the xml config as it is when first running orion? user username=admin password=x deactivated=false my application.xml: user-manager class=com.orionsupport.security.MyUserManager / should there be two different entries here??? one for the BASIC authen, and one for server admin ? my web.xml: security-role role-nameadministrators/role-name /security-role login-config auth-methodBASIC/auth-method realm-nameadmin tool/realm-name /login-config security-constraint web-resource-collection url-pattern/admin//url-pattern /web-resource-collection auth-constraint role-nameadministrators/role-name /auth-constraint /security-constraint my principals.xml: (however the user is just ignored, and the MyUserManager is always used to validate both users) principals groups group name=administrators descriptionadmin tool users/description permission name=administration / permission name=com.evermind.server.AdministrationPermission / /group /groups users user username=admin password=admin deactivated=false descriptionThe default administrator/description group-membership group=administrators / /user /users /principals I hope all that made sense thanks tim
RE: does orionsupport startup and shut down classes
See answer at www.elephantwalker.com/rfa?id=301 Regards, the elephantwalker -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of meera krishnaraja bhatSent: Wednesday, January 09, 2002 5:03 PMTo: Orion-InterestSubject: does orionsupport startup and shut down classes hai Does ORION support startup and shutdown classes? Here is the scenario, in order to have access to the system resources (file system, legacy applications) from an EJB, it is the violation of EJB spec. However, one can write a java class that accesses system resources and deployed this class in the EJB Server. thanks meera MSN Photos is the easiest way to share and print your photos: Click Here
Re: string mappings
Just create or alter the database table by hand. You can then assign whatever length to you varchar fields. We have disabled the autocreate-tables option in orion-application.xml and create all our tables by hand. hope that helps, Peter Morten Wilken wrote: hi all, i have a situation where i need to make an entitybean with a subject line and a body text in the class both these are implemented as Strings, but i need to map the subject to a short varchar (ie 50 chars) and the body text to a larger one (but not so large that i need to map it to a blob).. how do i differentiate between the 2 in the db schema? sincerely Morten Wilken -- Peter Beck, JOANNEUM RESEARCH Forschungsges.m.b.H. [EMAIL PROTECTED]
RE: Distributing EJBs
I should have mentioned that I tried this; it doesn't help. Further investigation reveals that Orion seems to save the Context that is first created in a Map using the application name as a key. Closing the context after use doesn't seem to remove it from this map. If you create a new InitialContext, the RMIInitialContextFactory will look up the implementation of an RMIContext in this (hypothetical) Map using the application name. If you specify an application name in the URL and you are within an Orion container (i.e. web OR EJB) that URL must have an application name that the container recognizes; that is, it must be the same application that the container is in, or a parent. Otherwise you get a NullPointerException in the RMIInitialContextFactory. I'm not sure what the purpose of this functionality is; it doesn't really help by preventing mistakes. Thanks for the suggestion though. Jim -Original Message- From: The elephantwalker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 09, 2002 7:43 PM To: Orion-Interest; Carroll, Jim Subject: RE: Distributing EJBs you may need to close the rmi connection before opening up another one. Do this with the context.close() method. Regards, the elephantwalker www.elephantwalker.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Carroll, Jim Sent: Wednesday, January 09, 2002 11:01 AM To: Orion-Interest Subject: RE: Distributing EJBs I should make it clear in what follows that I am trying to load balance the EJBs in an application, not the web side. I know how to set up clustering. What I can't get to work is distribution of a set of EJBs across several servers like the following: -- server1 / EJBs | server0 - | JSP/Servlet Based __| EJB Client | | | -- server2 / EJBs -Original Message- From: Carroll, Jim Sent: Wednesday, January 09, 2002 1:42 PM To: 'Orion-Interest' Subject: Distributing EJBs I have been trying to distribute the same application across several servers for the purposes of load balancing. The team at Orion seems to have purposely made this impossible. I am using the RMIInitialContextFactory from the web container (from a JSP page) in order to round robbin between two servers. The code is rather simple: Properties prop = new Properties; prop.put(java.naming.factory.initial, com.evermind.server.rmi.RMIInitialContextFactory); prop.put(java.naming.provider.url, ormi://server1/appName); ... fill in security credentials ... InitialContext ic = new IntialContext(prop); BeanHome bh = ic.lookup(EJBName); BeanRemote br = bh.create(); br.invokeMethod(); // this executes on server1 // Now try to execute it on server2 prop.put(java.naming.provider.url, ormi://server2/appName); InitialContext ic2 = new InitialContext(prop); BeanHome bh2 = ic2.lookup(EJBName); BeanRemote br2 = bh2.create(); br2.invokeMethod(); // this ALSO executes on server1 The initial url of the RMIInitialContextFactory is used UNTIL server1 fails. Then server2 will start working (again, for every call). That someone would always want the same server simply because: 1) they are withing a (web) container (I'm not sure if this works from a stand alone client or not either), and 2) the application is the same seems an absurd assumption on the part of the Orion developers. Is there a way around this? Thanks
RE: App server debugging -- HELP
I'm starting to use 'kill -3' but that again only shows the parent thread. kill -3 should dump a stack trace of all of the threads.
Re: jdbc problems
You closed the Statement object before you closed the ResultSet object. Check your code and make sure that you closed the ResultSet object first before closing the Statement. This is usually found in the finally clause of your JDBC code. --- JoseMa [EMAIL PROTECTED] wrote: Hi, I've a Orion server with Oracle datasources configured I've put the jdbc debug and in error file I look the next message : *** CLOSING STATEMENT WITH 1 OPEN RESULTSET AT: *** java.lang.Exception at com.evermind._bt.close(Unknown Source) at com.evermind._wq.close(Unknown Source) at com.evermind._bt.close(Unknown Source) at com.evermind._wq.close(Unknown Source) at com.evermind._bt.close(Unknown Source) In server-out I look the next message: new DebugConnection(1) Created new physical connection: XA XA Orion Pooled jdbc:oracle:thin:machine:port new DebugConnection(2) new DebugConnection(3) Created new physical connection: Pooled [Connection 3: oracle.jdbc.driver.OracleConnection@id] new DebugConnection(4) new DebugPreparedStatement(1) new DebugPreparedStatement(2) new DebugPreparedStatement(3) new DebugPreparedStatement(4) new DebugResultSet() new DebugResultSet() new DebugResultSet() new DebugResultSet() closing DebugPreparedStatement(1) closing DebugPreparedStatement(2) closing DebugPreparedStatement(3) closing DebugPreparedStatement(4) Pooled jdbc:oracle:thin:@machine:port Releasing connection Pooled [Connection 3: oracle.jdbc.driver.OracleConnection@id to pool (Pool size: 1) closing DebugConnection(4) null: Releasing connection XA XA Orion Pooled jdbc:oracle:thin:machine:port: to pool (Pool size: 1) closing DebugConnection(2) closing DebugConnection(1) closing DebugConnection(3) What does it mean? Could you help me? Thank, __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
ORMI-HTTP Tunneling through firewall with proxy server
Has anyone had any luck accessing EJBs using ORMI-HTTP tunneling when a firewall and a proxy server are being used? I've tried setting the system properties for proxySet, proxyHost, and proxyPort with no luck. After a long period of time, the client application exits with the following exception: javax.naming.NamingException: Lookup error: java.io.IOException: Did not receive valid HTTP headers; nested exception is: java.io.IOException: Did not receive valid HTTP headers at com.evermind.server.rmi.RMIContext.lookup(JAX) at javax.naming.InitialContext.lookup(InitialContext.java:350) at com.platts.dmz.DMZTestingClient.testDataTransfer(DMZTestiEnding test ngClient.java:174) at com.platts.dmz.DMZTestingClient.main(DMZTestingClient.java:285) We are using Orion version 1.4.5. Any ideas/suggestions? Thanks, Frank Frank Frederick Software Engineer/Architect Platts - A Division of McGraw-Hill www.Platts.com 720-548-5656
Re: Simple question re caching/pooling of BMP Entity Beans
My opinion would add; if not pooled OR not exclusive owner of data then ejbLoad exclusive owner is an orion-ejb-jar.xml propert. The default is, exclusively owns the data. curt Sergey G. Aslanov wrote: 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 through a GS Session Bean. I would expect that when I call findByPrimaryKey on my GS Entity Bean's home interface, Orion caches the instance it creates so GS that next time I call findByPrimaryKey for the same key, it just returns GS the instance it already has rather than creating a new one. However, it GS appears that it goes to the database (i.e. calls ejbFindByPrimaryKey in GS the Entity Bean's implementation) for every call to findByPrimaryKey, GS regardless of whether it has previously read the instance with the GS specified key before. GS I checked the list archive and it appears that someone has reported a GS similar problem a while back but there were no replies GS (http://www.mail-archive.com/orion-interest@orionserver.com/msg17359.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 Orion to GS 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 -- Curt Smith [EMAIL PROTECTED] (w) 404-463-0973 (h) 404-294-6686
Re: question about ip allocation
It seems to me what IIS have some bug or intend to work wrongly with Java. If www service of IIS shutted down there are no problem to have working third party web servers (two instances of orion server) on same port but different IP addresses on same Ethernet interface. Consider you options: -use third perty webserver -use different port and map port 80 on your firewall to web server's listening port on your computer. Hope it will help. - Original Message - From: Morten Raahede Knudsen [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, January 10, 2002 4:51 AM Subject: Re: question about ip allocation Hi all Thanks for all your informative responses! Sorry but that is just not true. You can have two processes each with their own address listening on the same port. In fact you can have a process per address since the unique combination must be address and port, the kernel sorts all the rest out. If you have netcat installed on your linux machine try the following nc -s ip1 -l -p 2000 in another terminal run nc -s ip2 -l -p 2000. Both processes will be bound to port 2000 and you can connect to each as you would expect. The original poster's problem is likely that he does not have IIS properly configured to listen on only one address. This is very interesting I've downloaded netcat for Windows 2000. I can't execute those two commands you've suggested. On the second command it says: Can't grab 192.168.1.86:2000 with bind Either the two versions of netcat differ or maybe it doesn't work on Windows? Thanks in advance, Morten Raahede Knudsen Morten Raahede Knudsen [EMAIL PROTECTED] Programmør Bilpriser.dk Tolderlundsvej 16 DK-5000 Odense C Telefon +45 6314 6065 Telefax +45 6619 2164 Ved du hvad din bil er værd? Besøg http://www.bilpriser.dk
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
Name-based Virtual Hosts
How can I configure name-based virtual hosts (vhosts) in Orion? I have one IP address that I need to host multiple domains on. Thanks, Mark A. Richman http://www.markrichman.com
Re: Simple question re caching/pooling of BMP Entity Beans
pooling definitely does work for BMP.
couple of things i found that you might want to check off.
1. implement an isModified method
public boolean isModified() {
return false;
}
which orion will check to determine if ejbLoad needs to be called. we're
using the value object pattern to the above works for us. you may want to
make it more complicated depending on your requirements.
2.. return a Collection from your finder methods. returning an Enumeration
seems to cause orion to not pool.
3. if you have defined your own primary key instead of using, say, Integer,
it seems you need to implement equals() and hashCode().
if you can't get it working maybe post the code from one of your bean
classes.
good luck,
greg.
- Original Message -
From: Geoff Soutter [EMAIL PROTECTED]
To: Orion-Interest [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 8:08 AM
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: Simple question re caching/pooling of BMP Entity Beans
Hi Guys. Having just finished solving some headaches on this topic, my comment is, what are you guys doing differently from me? One of our ex-guys was nice enough to write a mess of code to update data that an entity EJB used/stored, but rather than updating the EJB, the database was updated directly. Since the EJB (BMP) was being cached, not loaded, and had a verrry long time out (intentional), this was producing some really nasty bugs. To get the data to load, we had to stop and restart the server. And I can very that findByPrimaryKey was most definately getting called. One thing I did notice, from very early in the project. Left to its defaults, the timeout on an Entity EJB in Orion is very short. It may be unloaded between consecutive calls. For example, the following block of code did result in three calls of ejbLoad on the entity EJB until we reset the time-out. UserHome userHome = getUserHome(); //Returns home interface to UserEntityEJB User user = userHome.findByPrimayKey(username); //Returns Remote Interface to Entity EJB user.login(password); UserData data = user.getData(); I forget where off hand to set the EJB Time-out, but I think it was either the ejb-jar.xml, or the orion-ejb-jar.xml file. If you need, I can look it up and let you know. -Steve Geoff Soutter wrote: 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 -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
ORMI-HTTP Tunneling through firewall with proxy server
Hi, I have a similar problem but with a simple applet connecting to the JMS Server using ORMI-HTTP tunneling when a firewall and a proxyserver are used the client application times out when it calls start on topicConnection. Any ideas why is this happening? --- Frederick,Frank [EMAIL PROTECTED] wrote: Has anyone had any luck accessing EJBs using ORMI-HTTP tunneling when a firewall and a proxy server are being used? I've tried setting the system properties for proxySet, proxyHost, and proxyPort with no luck. After a long period of time, the client application exits with the following exception: javax.naming.NamingException: Lookup error: java.io.IOException: Did not receive valid HTTP headers; nested exception is: java.io.IOException: Did not receive valid HTTP headers at com.evermind.server.rmi.RMIContext.lookup(JAX) at javax.naming.InitialContext.lookup(InitialContext.java:350) at com.platts.dmz.DMZTestingClient.testDataTransfer(DMZTestiEnding test ngClient.java:174) at com.platts.dmz.DMZTestingClient.main(DMZTestingClient.java:285) We are using Orion version 1.4.5. Any ideas/suggestions? Thanks, Frank Frank Frederick Software Engineer/Architect Platts - A Division of McGraw-Hill www.Platts.com 720-548-5656 __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
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
Anyone got old orionsupport sample application client / scheduler?
You can see it described in googles cache http://www.google.com/search?q=cache:4nkQslt9AjsC:www.orionsupport.com/a rticles/appclient.html+orion+application+clienthl=en If anyone has the source jar file, I'd really appreciate a copy! Cheers Geoff
