Our project is designed in EJB 2.0.
We are not using any kind of EJB persistance methods in the BMP EntityBeans. In SessionBeans we are getting reference to EntityHome object by using method getEJBXXXXHome() method and there by calling home.findByPrimaryKey("") method to get the EJB reference. Then we are calling actual methods for CRUD operations. In CRUD operations methods our people have used normal JDBC API methods.
Now we are migrating to EJB3. As part of migration from EJB 2.0 TO EJB3 am converting all my BMP EntityBeans to normal Java classes i.e there are no more entitybeans. If EJB container maintains a pool for the entitybeans earlier, it wont be there now. Its working normally when I have tested in my local machine for one transaction
My concern is, will it affects the perfromance for multiple threads in production?.
Afer changing the code now, every call creates one EntityBean Object. If 60k calls were made in just one hour will that affect my server. How this one is handled previously in EJB 2.0? is there any way to handle it in the changed code (i.e for normal java classes as they are no more entitybeans concept)
Generally speaking, the overhead of objection creation/collection is going to be lower than the overhead of whatever the EJB container was doing for your entities previously. I suspect a larger concern than object creation overhead is round-trips to the database. Depending on your EJB container configuration, it's likely the container was optimizing the JDBC SQL and possibly caching the retrieved data (unrelated to object caching). You should likely design your application to minimize calls to the database and ensure you don't execute unnecessary queries.
Ultimately, I suspect only you are going to be able to assess the performance of your application on your application server on your hardware. I recommend following good programming practices to avoid egregious overhead, profile the result, and optimize from there rather than worrying about the performance up-front.
Related
Is it sensible to use Spring in the server side of an in memory data grid based application?
My gut feeling tells me that it is nonsense in a low latency high performance system. A colleague of mine is insisting on including Spring in it. What are the pros and cons of such inclusion?
My position is that Spring is OK to be used in the client but it is too heavy for the server, it brings too many dependancies and is one more leaky abstraction to think of.
Data Grid systems are memory and I/O intensive in general. Using Spring does not affect that (you may argue that Spring creates a lot of beans but with proper Garbage Collection tuning this is not a problem).
On the other hand using Spring (or any other DI) helps you structure and test your code.
So if you are using implementing some sort of server based on Data Grid systems, pay attention to properly adjusting GC, sockets in your OS (memory buffers and socket memories). Those will give you much more benefits than cutting down DI.
First, I'm surprised by the "leaky abstraction" comment. I've never heard anyone criticize Spring for this. In fact, it's just the opposite. Spring removes the implementation details of infrastructure such as data grids from your application code and provides a consistent and familiar programming model, allowing you to focus on business logic. Spring does a lot to enhance configuration and access to data grids, especially Gemfire, and generally does not create any runtime overhead per se. During initialization of a Spring application, Spring uses tools like reflection and AOP internally which may increase the start up time of an application, but this has no impact on runtime performance. Spring has been proven in many high-throughput, low-latency production applications. In extreme cases, things like network latency and serialization, concerns external to Spring, are normally the biggest factors affecting performance.
"Spring brings in too many dependencies" is a common complaint, but is a fallacy. I would say Spring brings in the exact right amount of dependencies for what it needs to do. Additionally, Spring Boot starters and the platform BOM do a lot to simplify dependency management so you don't need to worry about version incompatibilities or explicitly declaring common dependencies. I'll have to side with your colleague on this one.
I'm developing a file system which encapsulates access to an Amazon S3 bucket using the fuse library and jnr-fuse (https://github.com/SerCeMan/jnr-fuse) as a java binding.
I have a first version working and am currently doing some code-cleanup and refactoring work, trying to get everything into a proper multi-layered architecture.
So far I have roughly the following:
Frontend: This is the actual implementation of the FuseFileSystem interface from jnr-fuse. It has some dependencies to jnr (native) types and the methods are the java equivalents of fuse's c-functions.
Service Layer: One interface that has "non-native-dependent" versions of all the file-system methods from the frontend layer, but no dependencies to jnr or fuse whatsoever. The idea is that this could be used in other contexts as well (e.g. as the core component of an implementation of the java.nio.FileSystem-API for S3 or any other scenario where someone would need an API making S3 accessible in a "filesystem-ish" fashion but not want to do that via fuse and therefore not want all the jnr dependencies)
Where I'm currently struggling is the persistence layer: As all communication with S3 is actually done via http, I'm doing some fair amount of caching to reduce traffic and increase performance.
The question is where that caching would best fit..
Obviously the actual DAOs should not be polluted with any kind of caching/locking logic - they should only handle the actual access to the data (i.e. doing the http calls against S3).
On the other hand, also the service layer shouldn't really be concerned with caching (in case the persistence layer and with it the caching requirements change), so I was thinking of doing one of the following:
Use a "doubled" persistence layer: Each DAO is implemented twice: One version that holds a cache and serves data out of it's cache. If an object is not in the cache, we delegate to the second DAO which actually fetches the object (which is then added to the cache)
Introduce a separate "cache" layer with slightly different interfaces than the actual persistence layer that handles all caching requirements and delegates to the persistence layer as necessary.
Version 1 would be the cleaner one from the service-layer point of view - there wouldn't be any difference between using a cache and not using it because all calls to the persistence layer would go against the same interface. On the other hand it would also transfer all the logic concerning the state or "lifecycle" of a file (open -> read/write -> close) to the persistence layer.
Version 2 would manage the lifecycle of the file inside the "cache" layer, which I think would make the whole thing easier to understand for anyone new to the code. On the other hand it also assumes that there will always be a cache layer (which is probably true).
Are there any other pros and cons to the above approaches from a design point of view or is there any pattern out there which addresses this kind of problem?
Right now I'd rather go with option 2 but it'd be really interesting to hear some opinions.
Why are you opposed to caching in the DAO? This has always been the perfect place for me to cache. It is a data access concern, and thus goes into the data access layer. A couple of times I've used various AOP implementations for convenience, but 90% of the time, i'm implementing caching logic inside the DAO.
The cache itself does not live in the DAO, it is usually it's own interface, so I can swap between implementations (in-memory, on-disk, etc).
I have also had some luck when using Apache HTTP client's own built-in caching. It allows you to respect HTTP cache semantics, or override it with custom logic.
I have a Spring-WS web service that has three issues:
Slow startup time
Slow generation of the dynamic WSDL
Heavy usage of PermGen (app has to be 1.6 compatible)
Currently, the spring-ws-servlet.xml file has several <context:component-scan> elements for autowired dependencies. Two of these scan nearly everything in two external libraries containing Hibernate DAO and Entity classes. Similarly, the Hibernate session factory bean scans a large number of entities from these two libraries.
So, my questions:
Obviously, we would see at least some performance improvement by limiting the scope of the <context:component-scan> elements. But really, would it be that much?
Similarly, would I see improvements by limiting the scope of what Entities are scanned by the session factory?
Making these changes will NOT be a quick process (alter code, test, etc). Therefore, if anyone can add their wisdom, I would greatly appreciate it.
Actually I am developing a spring ws application on Google Cloud and I also have the same problem with slow start up time. The biggest difference that I have notice was when I have moved to aspectj compile time weaving using aspectj-maven-plugin. If you haven't done this yet try this one. The result may be vary depends on your code and deployment environment. On the cloud every file operation is much slower so this may be a reason why this work for me so well.
I'm building a JEE6 application with performance and scalability in the forefront of my mind.
Business logic and JPA2-facade is held in stateless session beans (EJB3.1). As of right now, the SLSBs implement only #Remote-interfaces. When a bean needs to access another bean, it does so via RMI.
My reasoning behind this is the assumption that, once the application runs on a bunch of clustered application servers, the RMI-part allows the execution to be distributed across the whole cluster automagically.
Is that a correct assumption?
I'm fine with dealing with the downsides of that (objects lose entityManager session, pass-by-value), at least I think so. But I am wondering if constant remote invocation isn't adding more load then necessary.
The EJB specification don't specify how clustering should be achieved, so this will depend on the particular implementation used. Actually, the EJB specifications are on purpose written to not make assumptions about the deployment: they don't mandate any support of clustering, but are written in a way that makes it possible (and a lot of restrictions in the EJB model stems from potential clustering issues, e.g. access to the file system). The implementer is then free to support clustering or not, and still comply with the spec.
In Glassfish, the reference to the remote EJB does the distribution itself. See my answer here for more information. Each request could potentially be dispatched to a different node. That's probably the way most implementations work. So I would say your assumption is correct.
I do hope however that they optimize the case when one EJB calls another EJB and try to dispatch the invacation on the same node whenever possible. That will depend whether the deployment is homogeneous or not (all nodes have the same beans, or not). Again, the spec are a bit vague regarding such points. But I guess that most deployment are homogeneous in practice: the same ear is deployed on all nodes.
Regarding the performance overhead of remote vs. local calls, I did some measures once (on Glassfish). See my answer here. Inter EJB calls in the same .ear through remote interface was 3x slower than local calls. That sounds big, but we are speaking of milliseconds, so the relative overhead depends on what the methods really does. I don't know the performance of other app. server.
Hope it helps.
What are the advantages and disadvantages of the Session Façade Core J2EE Pattern?
What are the assumptions behind it?
Are these assumptions valid in a particular environment?
Session Facade is a fantastic pattern - it is really a specific version of the Business Facade pattern. The idea is to tie up business functionality into discrete bundles - such as TransferMoney(), Withdraw(), Deposit()... So that your UI code is accessing things in terms of business operations instead of low level data access or other details that it shouldn't have to be concerned with.
Specifically with the Session Facade - you use a Session EJB to act as the business facade - which is nice cause then you can take advantage of all the J2EE services (authentication/authorization, transactions, etc)...
Hope that helps...
The main advantage of the Session Facade pattern is that you can divide up a J2EE application into logical groups by business functionality. A Session Facade will be called by a POJO from the UI (i.e. a Business Delegate), and have references to appropriate Data Access Objects. E.g. a PersonSessionFacade would be called by the PersonBusinessDelegate and then it could call the PersonDAO. The methods on the PersonSessionFacade will, at the very least, follow the CRUD pattern (Create, Retrieve, Update and Delete).
Typically, most Session Facades are implemented as stateless session EJBs. Or if you're in Spring land using AOP for transactions, you can create a service POJO that which can be all the join points for your transaction manager.
Another advantage of the SessionFacade pattern is that any J2EE developer with a modicum of experience will immediately understand you.
Disadvantages of the SessionFacade pattern: it assumes a specific enterprise architecture that is constrained by the limits of the J2EE 1.4 specification (see Rod Johnson's books for these criticisms). The most damaging disadvantage is that it is more complicated than necessary. In most enterprise web applications, you'll need a servlet container, and most of the stress in a web application will be at the tier that handles HttpRequests or database access. Consequently, it doesn't seem worthwhile to deploy the servlet container in a separate process space from the EJB container. I.e. remote calls to EJBs create more pain than gain.
Rod Johnson claims that the main reason you'd want to use a Session Facade is if you're doing container managed transactions - which aren't necessary with more modern frameworks (like Spring.)
He says that if you have business logic - put it in the POJO. (Which I agree with - I think its a more object-oriented approach - rather than implementing a session EJB.)
http://forum.springframework.org/showthread.php?t=18155
Happy to hear contrasting arguments.
It seems that whenever you talk about anything J2EE related - there are always a whole bunch of assumptions behind the scenes - which people assume one way or the other - which then leads to confusion. (I probably could have made the question clearer too.)
Assuming (a) we want to use container managed transactions in a strict sense through the EJB specification then
Session facades are a good idea - because they abstract away the low-level database transactions to be able to provide higher level application transaction management.
Assuming (b) that you mean the general architectural concept of the session façade - then
Decoupling services and consumers and providing a friendly interface over the top of this is a good idea. Computer science has solved lots of problems by 'adding an additional layer of indirection'.
Rod Johnson writes "SLSBs with remote interfaces provide a very good solution for distributed applications built over RMI. However, this is a minority requirement. Experience has shown that we don't want to use distributed architecture unless forced to by requirements. We can still service remote clients if necessary by implementing a remoting façade on top of a good co-located object model." (Johnson, R "J2EE Development without EJB" p119.)
Assuming (c) that you consider the EJB specification (and in particular the session façade component) to be a blight on the landscape of good design then:
Rod Johnson writes
"In general, there are not many reasons you would use a local SLSB at all in a Spring application, as Spring provides more capable declarative transaction management than EJB, and CMT is normally the main motivation for using local SLSBs. So you might not need th EJB layer at all. " http://forum.springframework.org/showthread.php?t=18155
In an environment where performance and scalability of the web server are the primary concerns - and cost is an issue - then the session facade architecture looks less attractive - it can be simpler to talk directly to the datbase (although this is more about tiering.)