Often, one needs to make sure that the data of one service/application is not inappropriately saved/cached in another service/application. This ensures the integrity of the data.
A single service/application may be responsible for providing a particular type of data. This data should not be cached or saved in another application. In this way, all data of this type is solely accessed from this application/service. All applications/services requesting this data would have to always retrieve it from this single service/application. Typically, however, other applications/services may reference data within this single application with an identifier or id which can be used and passed to the single service to access the actual original data. Therefore, data the actual data would not be replicated by the other services/application.
If the actual data were to be saved/cached in another application/service in order that the original service does not have to be called and thus improve performance, data integrity cannot be ensured. The data would then inadvertently be saved in two locations. If the data needs to change, one would have to update these two locations to ensure the integrity of the data.
This is a basic notion of application design.
Therefore, one needs to be careful in caching actual data that can be accessed from another service as opposed to simply saving the reference to the data which can be used for accessing the data in the originating service/application.
Wednesday, July 30, 2008
Wednesday, May 21, 2008
Database Views
Views should be created if a query is required for accessing data from multiple tables and multiple rows of multiple tables.
Thursday, May 1, 2008
CORE3282: Crash occurred in function
[01/May/2008:11:05:23] fine ( 6208): Successfully initialized web application environment for virtual server [https-bamws]
[01/May/2008:11:05:35] info ( 6208): CORE3282: stdout: WebappClassLoader: Additional JARs have been added : 'hibernate-3.2.3.jar'
[01/May/2008:11:05:39] info ( 6208): WEB2798: [] ServletContext.log(): WEB3945: Scratch dir for the JSP engine is: /opt/sunone/https-mtan/ClassCache/https-bamws/default-webapp
[01/May/2008:11:05:39] info ( 6208): WEB2798: [] ServletContext.log(): WEB3947: IMPORTANT: Do not modify the generated servlets
[01/May/2008:11:05:44] catastrophe ( 6208): CORE3260: Server crash detected (signal SIGSEGV)
[01/May/2008:11:05:44] info ( 6208): CORE3262: Crash occurred in function pblock*NVPairs::dup()const from module /opt/sunone/bin/https/lib/libns-httpd40.so
Scenario:
I removed all jars from WEB-INF/lib with rm -r *, populated it with a new lib directory, restarted the server and the above error occurred. Restarting the server every time still caused this same error.
I tried to remove all references to this web app in the server.xml file, but the error still occurred.
Cause:
This could have been possibly caused by the removal of jars that while the server was still running. Perhaps, an artifact of the jar remained after subsequent restarts and would continuously cause the crash on the server.
Solution:
I removed the hibernate-3.2.3.jar from this lib directory and the web server now starts without error.
[01/May/2008:11:05:35] info ( 6208): CORE3282: stdout: WebappClassLoader: Additional JARs have been added : 'hibernate-3.2.3.jar'
[01/May/2008:11:05:39] info ( 6208): WEB2798: [] ServletContext.log(): WEB3945: Scratch dir for the JSP engine is: /opt/sunone/https-mtan/ClassCache/https-bamws/default-webapp
[01/May/2008:11:05:39] info ( 6208): WEB2798: [] ServletContext.log(): WEB3947: IMPORTANT: Do not modify the generated servlets
[01/May/2008:11:05:44] catastrophe ( 6208): CORE3260: Server crash detected (signal SIGSEGV)
[01/May/2008:11:05:44] info ( 6208): CORE3262: Crash occurred in function pblock*NVPairs::dup()const from module /opt/sunone/bin/https/lib/libns-httpd40.so
Scenario:
I removed all jars from WEB-INF/lib with rm -r *, populated it with a new lib directory, restarted the server and the above error occurred. Restarting the server every time still caused this same error.
I tried to remove all references to this web app in the server.xml file, but the error still occurred.
Cause:
This could have been possibly caused by the removal of jars that while the server was still running. Perhaps, an artifact of the jar remained after subsequent restarts and would continuously cause the crash on the server.
Solution:
I removed the hibernate-3.2.3.jar from this lib directory and the web server now starts without error.
Monday, April 28, 2008
NoSuchMethodError: javax.xml.parsers.DocumnentBuilderFactory.getSchema()
java.lang.NoSuchMethodError: javax.xml.parsers.DocumentBuilderFactory.getSchema()Ljavax/xml/validation/Schema;
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
Cause: You are using a different version of the DocumentBuilderFactory class
Solution:
This version of the javax.xml.parsers.DocumentBuilderFactory is used by the xercesImpl.jar and is defined in the jaxp-api.jar
This class is defined in the following jars:
xml-apis.jar
xmlParserAPIs.jar
xercesImpl-2.8.1.jar
jaxp-api.jar
In addition, this class is also include in the JVM. The JVM implementation of this class does not define a getSchema() method.
The only jar that contains an implementation of the DocmentBuilderFactory with the getSchema() method defined is the jaxp-api.jar. In order for this implementation to be used instead of the JVM's implementation or the other jar's implementation, you must either endorse this jar or put this jaxp-api.jar at the top of the classpath.
NoClassDefFoundError: com/sun/org/apache/xerces/internal/dom/DocumentImpl
java.lang.NoClassDefFoundError: com/sun/org/apache/xerces/internal/dom/DocumentImpl
at java.lang.ClassLoader.defineClass0(Native Method)
..........
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.(SOAPPartImpl.java:63)
at com.sun.xml.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.(SOAPPart1_1Impl.java:29)
at com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl.getSOAPPart(Message1_1Impl.java:52)
at
Cause: Missing a class
Solution:
There are two versions of the xercesImpl.jar that define the different classes in different packages. These packages are the following:
com.sun.org.apache
org.apache
The DocumentImpl class is defined in the following packages of each corresponding jar:
com.sun.org.apache.exerces.internal.dom
org.apache.xerces.dom
The jar that contains the DocumentImpl of the NoClassDefFoundError is contained in the first jar. Please include this jar in the classpath before the second version of the jar.
Reference:
http://mail-archives.apache.org/mod_mbox/xerces-j-users/200407.mbox/%3C40F0D3AD.3050201@sun.com%3E
Monday, April 21, 2008
Mule Error: Application does not seem to be starting or is hanging
Error:
Launching a JVM...
Error [125] in bind() call!
err:: Address already in use
Socket transport failed to init.
Transport dt_socket failed to initialize, rc = -1.
FATAL ERROR in native method: No transports initialized
JVM exited while loading the application.
------------------------------------------------------------------------
The JVM is being launched with a debugger enabled and could possibly be
suspended. To avoid unwanted shutdowns, timeouts will be disabled,
removing the ability to detect and restart frozen JVMs.
------------------------------------------------------------------------
The logs display the above error.
This indicates that the port for debugging is already in use, and not the actual mule application's port.
Change the debug port in the wrapper.conf.
wrapper.java.additional.5=-Xrunjdwp:transport=dt_socket,address=5295,server=y,suspend=y
Launching a JVM...
Error [125] in bind() call!
err:: Address already in use
Socket transport failed to init.
Transport dt_socket failed to initialize, rc = -1.
FATAL ERROR in native method: No transports initialized
JVM exited while loading the application.
------------------------------------------------------------------------
The JVM is being launched with a debugger enabled and could possibly be
suspended. To avoid unwanted shutdowns, timeouts will be disabled,
removing the ability to detect and restart frozen JVMs.
------------------------------------------------------------------------
The logs display the above error.
This indicates that the port for debugging is already in use, and not the actual mule application's port.
Change the debug port in the wrapper.conf.
wrapper.java.additional.5=-Xrunjdwp:transport=dt_socket,address=5295,server=y,suspend=y
Tuesday, April 8, 2008
CSS
So, I'm creating a website and I'm noting some things down about CSS I'm learning from an actual site. Cool dudes.
CSS Styles
position: relative |
color: #ABC123
background-color: #ABC123
font:
font-size: XXXpx | XXX
width: XXXpx
margin: XXXpx
margin-bottom: XXXpx
margin-right:
padding:
text-align: center |
border: XXX
CSS Styles
position: relative |
color: #ABC123
background-color: #ABC123
font:
font-size: XXXpx | XXX
width: XXXpx
margin: XXXpx
margin-bottom: XXXpx
margin-right:
padding:
text-align: center |
border: XXX
Subscribe to:
Posts (Atom)