Matjaz Juric

Author
+ Follow
since Aug 02, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Matjaz Juric

EJBs are not allowed to start threads. This is what EJB spec says (24.1.2):
"The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups."
Cheers,
Matjaz

Originally posted by Thomas Paul:
But just because the week is over doesn't mean you have to go away, Matjaz.


I didn't go away
Caching home object references is ok and it can be a real performance improvement. Actually in the Professional EJB book you can find out how to develop smart stubs for EJBs, where you can cache some remote method invocations on the client side already. It's relatively transparent and easy to develop.
Cheers,
Matjaz
[ February 11, 2002: Message edited by: Matjaz Juric ]
Hi Rajeev,
I agree with your explanation.

Originally posted by Rajeev Gupta:
As far as it concern with implementing both the interface, The Virtual machine will have a problem as to transffer an object with what techinque(Serialization or Remote).


As I've mentioned previously, the rmic compiler will detect some situations where this occurs and refuse to generate stubs. It would be really nice to hear whether the JVM spec says something about this – if it is really up to the JVM implementation, this may cause incompatibilities between different JVMs.
Cheers,
Matjaz
Hi Thomas,

Originally posted by Thomas Paul:
It would appear that this can only work if the client has access to the remote object class itself and not just the remote interface. Perhaps that is why Serializable/Remote is used in the java.rmi.server package?


I believe that java.rmi.server.RemoteObject implements both, Remote and Serializable to provide a way to generate stubs for remote objects.
Cheers,
Matjaz
Hi Doug,

Originally posted by Doug Wang:
What if a Remote object itself acts as a parameter to pass across machines?


If you use a Remote object as a method parameter or a return value, then a remote reference is sent. If a Serializable object is used as a method parameter or a return value, then the object is serialized and sent over the wire to the remote JVM, where it is instantiated.
Cheers,
Matjaz
Hi Thomas,

Originally posted by Thomas Paul:
I got a clean compile and a clean rmic on this:


I think our discussion is getting very interesting. I’ve tried what you’ve recommended, however if I remove the Wire interface, how can the Client (which can be located on a remote computer, and therefore does not have access to WireImpl – it should only have access to the interface of the remote object, not its implementation) get the Hello object?
Cheers,
Matjaz

Originally posted by Aftab:
But in my code I want to find by workflowcode and eventname(instead of eventcode). How should I do this with CMP?? My EJB book says this is vendor specfic for each App server. But does explain how it is done. With BMP this would be straightforward..you just write JDBC code for each finder.


As far as I know, JBoss is EJB 2.0 compliant. That means that you can use CMP 2.0 with EJB QL, so you can place queries in the deployment descriptor.
Congratulations to the winners. I was glad to be here, it was a pleasure.
Cheers!
Hi Bill,

Originally posted by Bill Bailey:
On what "tool" are these examples based.
Are they vendor independant, or did you choose to use WebLogic, Websphere, Oracle 9iAS.... with the specificities it can sometimes imply ?


Most of the examples in the book are prepared for BEA WebLogic 6.1, because by the time of writing the book it was the only EJB 2.0 (and J2EE 1.3) compliant app server (at least I didn't know of any other). However, the examples should also work on any other server, without modifications.
Cheers,
Matjaz
Hi Thomas/Ram,

Originally posted by Thomas Paul:

This is incorrect. Look at the RemoteObject class which is in the package java.rmi.server:
http://java.sun.com/j2se/1.3/docs/api/java/rmi/server/RemoteObject.html
It implements both Remote and Serializable.


It is true, that a class can implement both, the Remote and the Serializable interface. However such object CANNOT be passed over the wire (this was the original question).
Try the following:
public interface Hello extends Remote {
public String sayHello() throws RemoteException;
}
public class HelloImpl extends PortableRemoteObject implements Hello, Serializable {
...
}
public interface Wire extends Remote {
public HelloImpl returnHelloObj() throws RemoteException;
}
public class WireImpl extends PortableRemoteObject implements Wire {
public WireImpl () throws RemoteException {
super();
}
public HelloImpl returnHelloObj() {
HelloImpl h = null;
try {
h = new HelloImpl();
} catch (Exception e) {
System.out.println(e);
}
return h;
}
}
After compilation with javac we have to generate stubs and skeletons using rmic:
rmic -iiop HelloImpl
rmic -iiop WireImpl
Here we get the following error message:
error: HelloImpl is a remote implementation class and cannot be used as a method argument or return type in Wire.
error: Class Wire contains an invalid return type.
2 errors
Hi Dieter,

Originally posted by Dieter Cailliau:
Where i really need an answer is: what happens if one entity bean (with pk "12") is accessed by two clients, and all it's methods are transaction required. Are two threads going toghether over the bean, and is the transaction enforced in the database by the database mechanisms, or is it the j2ee container who denies access to the second thread because it knows the first thread is in transaction?[/URL]


As far as I know, the following happens if two or more clients access the same entity bean, each in a transaction:
- The first client accesses the entity bean in a transaction; the container delegates the transaction to the database. If optimistic locking is used (which is the case in most servers today) read locks are put on the data. Otherwise read/write locks are used.
- The second client accesses the same entity bean in a transaction. If optimistic locking is used, the second client can access the bean (the data), because it can put read locks on the same data. If pessimistic locking is used, the second client has to wait until the first one release the locks.
- The real interesting thing happens when one of the clients wants to modify the data (write). If optimistic locking is used, the read locks have to be upgraded to read/write locks. Only one client can do such upgrade. (If pessimistic locking is used, no upgrade is necessary).
- In certain situations this can lead to deadlocks, for example if both clients are waiting to upgrade their read locks to read/write locks. This is usually handled by database lock prevention mechanisms. In most databases a timeout can be specified. This timeout would cancel one of the locks, making it possible for the other client to upgrade locks to read/write.
This scenario can get quite complicated and I outlined it only. How much access is granted to simultaneous clients also depends on the transaction isolation level. There are also differences in details between app servers and DBMS.
Hope this will help,
Matjaz
Rulin,

Originally posted by Rulin Yang:
If I use URL/URLConnection, I have to do some code in the server side to read InputSteam and write outStream. I am not sure how I can do it. My legacy system my not allow me to do any coding.


Please look at the following links, they might help:
http://www.ecs.umass.edu/ece/wireless/people/emmanuel/java/networking/urls/readingWriting.html
http://home.att.net/~baldwin.rick/Advanced/Java556.htm
http://www.javaworld.com/javaworld/jw-03-2001/jw-0323-traps.html
Hi Dieter,

Originally posted by Dieter Cailliau:
Why is an ejb non-re-entrant by default? What's the good thing about this restriction? I don't see the point, i would never have thought about "hey maybe we could provide a mechanism that disallows ejb A to call back itself with another ejb in between". So what?


If an entity bean is marked as non-reentrant, then a container can prevent illegal concurrent calls from clients.
A reentrant entity bean on the other hand has to be programmed so that a loopback call is allowed. The container however cannot distinguish from a loopback and concurrent call from a different client, the developer has to avoid situations that could lead to a concurrent call in the same transaction context, which is illegal.
Matjaz