Search Results

Search found 8 results on 1 pages for 'smayers81'.

Page 1/1 | 1 

• How to modernize an enormous legacy database?

  - by smayers81

  I have a question, just looking for suggestions here. So, my application is 'modernizing' a desktop application by converting it to the web, with an ICEFaces UI and server side written in Java. However, they are keeping around the same Oracle database, which at current count has about 700-900 tables and probably a billion total records in the tables. Some individual tables have 250 million rows, many have over 25 million. Needless to say, the database is not scaling well. As a result, the performance of the application is looking to be abysmal. The architects / decision makers-that-be have all either refused or are unwilling to restructure the persistence. So, basically we are putting a fresh coat of paint on a functional desktop application that currently serves most user needs and does so with relative ease and quick performance. I am having trouble sleeping at night thinking of how poorly this application is going to perform and how difficult it is going to be for everyday users to do their job. So, my question is, what options do I have to mitigate this impending disaster? Is there some type of intermediate layer I can put in between the database and the Java code to speed up performance while at the same time keeping the database structure intact? Caching is obviously an option, but I don't see that as being a cure-all. Is it possible to layer a NoSQL DB in between or something?

  Read the article

• DTO or Domain Model Object in the View Layer?

  - by smayers81

  I know this is probably an age-old question, but what is the better practice? Using a domain model object throughout all layers of your application, and even binding values directly to them on the JSP (I'm using JSF). Or convert a domain model object into a DTO in the DAO or Service layer and send a lightweight DTO to the presentation layer. I have been told it makes no sense to use DTOs because changes to the database will result in changes to all your DTOs whereas using Model Objects everywhere will just require changes to the affected model object. However, the ease of use and the lightweight nature of DTOs seems to outweigh that. I should note that my app uses Hibernate Model Objects AND uses its own custom-created model objects (meaning not bound to any DB session, always detached). Is either of the above scenarios more beneficial to a strict Model Object pattern? Using Hibernate has been a huge PITA with regards to things like Lazy Initialization Exceptions.

  Read the article

• How does Seam store conversation state in the client browser?

  - by smayers81

  Seam's documentation says that conversational state can be configured to be stored in the client browser as opposed to the servlet session. Can anyone tell me: How is this configuration set? How does Seam actually internally store the conversational state in the browser?

  Read the article

• Using Spring's KeyHolder with programmatically-generated primary keys

  - by smayers81

  Hello, I am using Spring's NamedParameterJdbcTemplate to perform an insert into a table. The table uses a NEXTVAL on a sequence to obtain the primary key. I then want this generated ID to be passed back to me. I am using Spring's KeyHolder implementation like this: KeyHolder key = new GeneratedKeyHolder(); jdbcTemplate.update(Constants.INSERT_ORDER_STATEMENT, params, key); However, when I run this statement, I am getting: org.springframework.dao.DataRetrievalFailureException: The generated key is not of a supported numeric type. Unable to cast [oracle.sql.ROWID] to [java.lang.Number] at org.springframework.jdbc.support.GeneratedKeyHolder.getKey(GeneratedKeyHolder.java:73) Any ideas what I am missing?

  Read the article

• When do you learn from your mistakes?

  - by smayers81

  When are you supposed to learn from your mistakes in coding / design? Is it something you take with you to the next project or do you learn in the middle of your current one, sacrificing consistency for cleaner, more well-informed code? For example, my application can be distinctly demarcated down two lines of business -- say one side is for sales and the other is for marketing. Both are somewhat tied together, but as far as the team structure, use cases, developers, etc. the app consists of the Sales code and the Marketing Code. Now, say the Sales code went in first and while good-intentioned, made some bad mistakes. Should the Marketing Code follow suit and make the same mistakes for the sake of consistency or should Marketing architects and designers instead learn from the mistakes that Sales made and developer a cleaner codebase, even though Sales and Marketing are in the exact same system? Basically, do you learn from your mistakes while in a project or do you continue to pile crap on top of crap?

  Read the article

• How do I pass parameters between request-scoped beans

  - by smayers81

  This is a question that has been bothering me for sometime. My application uses ICEFaces for our UI framework and Spring 2.5 for Dependency Injection. In addition, Spring actually maintains all of our backing beans, not the ICEFaces framework, so our faces-config is basically empty. Navigation is not even really handled through navigation-rules. We perform manual redirects to new windows using window.open. All of our beans are defined in our appContext file as being request-scoped. I have Page ABC which is backed by BackingBeanABC. Inside that backing bean, I have a parameter say: private Order order; I then have Page XYZ backed by BackingBeanXYZ. When I redirect from page ABC to page XYZ, I want to transfer the 'order' property from ABC to XYZ. The problem is since everything is request-scoped and I'm performing a redirect, I am losing the value of 'description'. There has got to be an easier way to pass objects between beans in request scope during a redirect. Can anyone assist with this issue?

  Read the article

• Documenting logic in javadoc

  - by smayers81

  I have a question about where to document logic in javadocs. For example, I have the following method signature in an interface: public int getTotalAssociationsAsParent(Long id, Long type); The method returns associations where the given ID is the parent and the association is of type 'type'. ID is required, but if type passed in is NULL, then I will return ALL associations where the ID is the parent. My question is where should this type of logic be documented? I hesitate putting it in the javadoc of the interface because that sort of constrains all implementing classes to adhere to that logic. Maybe in the future, I'll have an Impl class that throws an IllegalArgumentException if type is NULL. However, if I put it in non-javadoc in the Impl class, then consumers of this method won't know how the method behaves with a NULL type.

  Read the article

• Is it possible to perform a forward into a new window?

  - by smayers81

  We are using ICEFaces 1.8 and I would like to perform a forward to a new URL, but want it to open in a new window. We are currently able to perform a redirect to a new window as: public static void redirectToUrl(String urlPath) { if (urlPath != null) { try { final String url = FacesUtil.getContextPath() + urlPath; final StringBuffer jsCommand = new StringBuffer(); jsCommand.append("window.document.location.href='").append(url).append("';"); JavascriptContext.addJavascriptCall(FacesContext.getCurrentInstance(), jsCommand.toString()); } catch (Exception e) { throw new RuntimeException(e); } } } But is a forward possible using a similar approach?

  Read the article

1