mmm... Then probably "fastness" is a relative concept. What I would like to achieve is an external application which uses ofbiz and scales.
The application might not need to access ofbiz all the time, i.e. it should scales on its own by spawning itself on different servers (see amazon ec2). I think that using RMI in this context might make sense (correct me please) because the overload of "serialization" is on the client (which can scale easier), and I think there is even a bit more then simple serialization because RMI insist on executing on the client side part of the code before the actual serialization. (it is not only required the interface to the objects, but also the actual code, see for example my problem with the logger) I am not an expert in RMI! This is only reverse engineering! I might be wrong! This was a new concept for me, coming from plain old RPC. Indeed REST is probably "network" fast but would not account for the load on the servers. (not that RMI does). Or in other words you might need to scale ofbiz itself. It is already a solution I am considering. If all MySQL calls can be assumed to be atomic, which should be the case. I guess that the optimal solution is the one that works. But in this respect: would OfBiz move toward REST? And optimize it for that? Or would it move toward a solid accounting engine library? Thanks a lot! F -- View this message in context: http://ofbiz.135035.n4.nabble.com/RMI-null-GenericValue-userLogin-problem-tp4645375p4647143.html Sent from the OFBiz - User mailing list archive at Nabble.com.
