RE: How can I get UserTransaction or TransactionManager
Hi HK, you can't get UserTransaction from an Application-Client-or RMI-Client-Context. This (optional) feature is not supported by Orion. Heinz -Ursprüngliche Nachricht- Von: HyungKee Hwang [mailto:[EMAIL PROTECTED]] Gesendet am: Montag, 9. Juli 2001 02:35 An: Orion-Interest Betreff: RE: How can I get UserTransaction or TransactionManager Thank you Aby I tried java:comp/env/UserTransaction, but the same error occurred. Any advice appreciated. Regards, -HK -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Saturday, July 07, 2001 3:47 PM To: Orion-Interest Subject: Re: How can I get UserTransaction or TransactionManager Hi HK, I think you should try java:comp/env/UserTransaction Regards Aby HyungKee Hwang [EMAIL PROTECTED]@orionserver.com on 07-07-2001 09:10:55 AM Please respond to Orion-Interest [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] cc: Subject: How can I get UserTransaction or TransactionManager Hello, all. Can you give me some advice how to get UserTransaction or TrasactionManger? I wrote some codes in my application as follows; // Below codes are from Orion FAQ import javax.naming.*; import javax.transaction.*; ... TransactionManager manager = (TransactionManager)new InitialContext ().lookup(java:comp/UserTransaction); I didn't have any problem compiling my codes, but I met below error while running my application avax.naming.NameNotFoundException: java:comp/UserTransaction not found at com.evermind.server.rmi.RMIContext.lookup(JAX) Thank you in advance. -HK
AW: java:comp/Administrator
Hello Greg,
try the dissambler:
D:\orion%java_home%\bin\javap -classpath orion.jar
com.evermind.server.administration.ApplicationAdministrator
Heinz
-Ursprngliche Nachricht-
Von: Greg Matthews [mailto:[EMAIL PROTECTED]]
Gesendet am: Freitag, 23. Mrz 2001 05:15
An: Orion-Interest
Betreff: java:comp/Administrator
Dear all,
By following some code in a previous post i can get a reference to an
Administrator object
which lets me do things like get the application.xml display-name.
ApplicationAdministrator admin =
(ApplicationAdministrator)ctx.lookup("java:comp/Administrator");
System.out.println( admin.getDisplayName());
Does anyone know what other Orion objects are available to bind to?
As an aside, if i try to iterate through the object under java:comp with a
NamingIterator i
only get the following, which is strange because i was expecting to see
Administrator there (?)
UserTransaction: com.evermind.server.ApplicationServerTransactionManager
RoleManager: com.evermind.server.hm
Logger: com.evermind.util.CollectionLogger
UserManager: com.evermind.server.XMLUserManager
env: com.evermind.naming.j_
ThreadPool: com.evermind.server.he
Thanks,
Greg.
AW: AW: Entity beans never changed back to the pool.
Hi Robert,
Of course this is not an offical and documented way and I would it never use
in production.
It's the result of playing around with the orion-console and analyzing the
interface "ApplicationAdministrator" with javap.
Heinz
-Ursprüngliche Nachricht-
Von: Robert Krueger [mailto:[EMAIL PROTECTED]]
Gesendet am: Mittwoch, 8. November 2000 10:56
An: Orion-Interest
Betreff: Re: AW: Entity beans never changed back to the pool.
At 08:12 08.11.00 , you wrote:
Hello Esteban,
I posted the same question some months ago.
In this list there are several mails concerning the cache-strategy of
entity-beans in the orion-container - but unfortunately we never got
answers
from the developer-team.
I found a way to flush the cache automatically.
You can use the class
com.evermind.server.administration.ApplicationAdministrator
from orion.jar in the following way (application-client or session-bean):
...
import com.evermind.server.administration.*;
...
Context context = new InitialContext();
ApplicationAdministrator admin =
(ApplicationAdministrator)context.lookup("java:comp/Administrator");
...
admin.flushEJBCache("name of your entity-bean");
...
is this offically exposed and documented? if not, what makes you think they
don't change the interface in the next version regardless of whether you've
coded against it?
robert
All beans will be flushed, it works fine.
But the virtual memory of the JVM don't change (WinNT, JDK 1.3, Orion
1.4.0).
Kind regards
Heinz Häußler
Eurocopter Deutschland GmbH
D/KDC
Postfach 13 53
86603 Donauwörth
Tel.: +49 (0) 906 / 71-4431
Fax.: + 49 (0) 906 / 71-4100
Mail: mailto:[EMAIL PROTECTED]
Home: http:\\www.eurocopter.com
-Ursprüngliche Nachricht-
Von: Lopez Esteban [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 6. November 2000 20:07
An: Orion-Interest
Betreff: Entity beans never changed back to the pool.
Hello, I plan to use Orion-Server for a big Database-Application with Java-
and Web-Clients.
I'm using Orion version 1.4.0. After serveral tests we noticed, that once a
Entity-Bean was instanced and used, it never changed back to the pool. The
number of usered instances grows and grows until I manually flush the cache
in the Console-Utility.
With this strategy, the Server will run out of memory after some time. Is
it
possible to limit the number of used and pooled Entity-Bean instances ? I
can't find any parameter in the xml-Files.
Best regards
Esteban
(-) Robert Krüger
(-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
(-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
AW: Entity beans never changed back to the pool.
Hello Esteban,
I posted the same question some months ago.
In this list there are several mails concerning the cache-strategy of
entity-beans in the orion-container - but unfortunately we never got answers
from the developer-team.
I found a way to flush the cache automatically.
You can use the class
com.evermind.server.administration.ApplicationAdministrator
from orion.jar in the following way (application-client or session-bean):
...
import com.evermind.server.administration.*;
...
Context context = new InitialContext();
ApplicationAdministrator admin =
(ApplicationAdministrator)context.lookup("java:comp/Administrator");
...
admin.flushEJBCache("name of your entity-bean");
...
All beans will be flushed, it works fine.
But the virtual memory of the JVM don't change (WinNT, JDK 1.3, Orion
1.4.0).
Kind regards
Heinz Häußler
Eurocopter Deutschland GmbH
D/KDC
Postfach 13 53
86603 Donauwörth
Tel.: +49 (0) 906 / 71-4431
Fax.: + 49 (0) 906 / 71-4100
Mail: mailto:[EMAIL PROTECTED]
Home: http:\\www.eurocopter.com
-Ursprüngliche Nachricht-
Von: Lopez Esteban [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 6. November 2000 20:07
An: Orion-Interest
Betreff: Entity beans never changed back to the pool.
Hello, I plan to use Orion-Server for a big Database-Application with Java-
and Web-Clients.
I'm using Orion version 1.4.0. After serveral tests we noticed, that once a
Entity-Bean was instanced and used, it never changed back to the pool. The
number of usered instances grows and grows until I manually flush the cache
in the Console-Utility.
With this strategy, the Server will run out of memory after some time. Is it
possible to limit the number of used and pooled Entity-Bean instances ? I
can't find any parameter in the xml-Files.
Best regards
Esteban
AW: Orion JNDI implementation
Hi Gary,
try:
for (enum = context.list("java:comp"); enum.hasMore(); ) {
System.out.println(enum.next());
}
Heinz
-Ursprüngliche Nachricht-
Von: Gary Shea [mailto:[EMAIL PROTECTED]]
Gesendet am: Dienstag, 10. Oktober 2000 19:41
An: Orion-Interest
Betreff: Orion JNDI implementation
Hey, has anyone tried traversing the JNDI tree from within an Orion
application? I am unable to use the list() method to traverse down
into the env subtree, either that or there's nothing in the env subtree.
The env subtree is an object of the com.evermind.naming.jv class,
which implements Context, but list() on the env object returns an
empty enumeration. Is that because it's really empty, or because
evermind provided a null implementation of list()?
Thanks,
Gary
AW: How to use EJB2.0 on Orion
Hello Magnus, i studied this ATM-example and compared it with the ejb-2.0-specification. I don't understand the dependent-class "LogEntry": Is it a dependent object class or a dependent value class ? 9.4.3 of the spec tells us for a dependent object class: - can be the value of a cmr-field - cannot be the value of a cmp-field - must not be serializable a dependent value class: - can be the value of a cmp-field - cannot be the value of a cmr-field - mus bei serializable In the ATM-example, the LogEntry-Class is serializable and a Collection of LogEntries is a cmp-fields as well as a cmr-field. In my opinion a cmp-field cannot be a cmr-field. Tell me if i am wrong. Kind regards Heinz Häußler Eurocopter Deutschland GmbH D/KDC Postfach 13 53 86603 Donauwörth Tel.: +49 (0) 906 / 71-4431 Fax.: + 49 (0) 906 / 71-4100 Mail: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Home: http:\\www.eurocopter.com http://www.eurocopter.com/ -Ursprüngliche Nachricht- Von: Magnus Rydin [mailto:[EMAIL PROTECTED]] Gesendet am: Donnerstag, 21. September 2000 12:05 An: Orion-Interest Betreff: RE: How to use EJB2.0 on Orion Well, its basically my fault. The ATM has been running EJB 2.0 since the night it was implemented in Orion, I just thought I should do an effort to document the application before putting it up there for public access. Anyway, as previously said, its now available at http://www.orionserver.com/orion/applications/atm.ear http://www.orionserver.com/orion/applications/atm.ear Please notice that it will change over time, whenever a new part of EJB 2.0 or Servlet 2.3 is implemented. WR -Original Message- From: Christian Sell [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: den 20 september 2000 21:41 To: Orion-Interest Subject: Re: How to use EJB2.0 on Orion I have been sending this mail for quite some time but to no avail. well, maybe there IS no avail. Not many of us have done EJB 2.0 yet, and as far as the orion core team goes, I hope (!!) they are busy writing documentation for the basic stuff (and improving orion in their spare time). regards
Unlimited EntityBean-Instances
Hello, we plan to use Orion-Server for a big Database-Application with Java- and Web-Clients. For the first tests I used version 1.0.3b and last week I migrated to 1.2.9. After serveral tests we noticed, that Entity-Beans have changed their behavior in the instance-pool (toward 1.0.3b). Once a Entity-Bean was instanced and used, it never changed back to the pool. The number of usered instances grows and grows until I manually flush the cache in the Console-Utility. With this strategy, the Server will run out of memory after some time. Is it possible to limit the number of used and pooled Entity-Bean instances ? I can't find any parameter in the xml-Files. Kind regards Heinz Häußler Eurocopter Deutschland GmbH D/KDC Postfach 13 53 86603 Donauwörth Germany Tel.: +49 (0) 906 / 71-4431 Fax.: + 49 (0) 906 / 71-4100 Mail: mailto:[EMAIL PROTECTED] Home: http:\\www.eurocopter.com
