Stephan Mueller

Ranch Hand
+ Follow
since May 05, 2010
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Stephan Mueller

Hi. We are using Hibernate with the Arjuna JTA Manager and Springs Transactional support (annotation etc)

Imagine the following scenario

The expectation is, that in case of a RTE in the outer TX, the "important stuff" in the new TX is done and committed.
But what happens is, that the RTE from the outer TX seems to implicitely set a globalRollback Flag (basic handling of RTEs in this transaction scenario?). Now when the new TX (with the important stuff) tries to commit, Springs AbstractPlatformTransactionManager throws an exception like "Transaction silently rolled back because it was marked rollback only". Sorry, don't have exact Stacktrace here atm. I can post it tomorrow.

My question is: what is the exact reason for this behaviour? How can I circumvent it? Is the RTE really the problem here? Is the basic assumption, that the new TX can commit while the outer TX rolls back, correct or is it plain stupid?
Additionally let's assume, I can't change the expected transaction type to a checked exception

Looking forward to read your thoughts on this

Praful Thakare wrote:also, is there any pattern for the failed date/time? you mentioned it fails 3 times a year, what is that time?

As far as I can tell, there's no pattern. "3 times a year" should read "it failed 3 times in the last year".

Regarding the timeOffset: I'll look into that.
11 years ago

have you considered it could be concurrency issue?

Yes. But as I could not reproduce the problem, I've tried to wrap my head around the underlying code. The Date used to populated the datetime field is not shared among threads. Or are the concurrency issues regarding date even more invasive?
I'll reiterate over the code to eliminate that.
11 years ago

Once in a while (happened 3 times in 1 year) our application uses a wrong Date(time).
Overview: Our application uses Spring 3, Hibernate, MySQL 5 and runs in a Tomcat 6 instance. We have configured the MySQL Instance to store Datetime values in UTC (see JDBC Driver config below). Our application uses a TimeService class to generate dates if needed.
From what I can tell, there's no place were we set the Timezone manually - the TimeService uses the defaultTimezone (see Code below). Affected Fields on entites are defined as Hibernate TIMESTAMP.
The production system is a 64-Bit Linux for System z with Suse Linux Enterprise Server 11.2 using IBM Java Development Kit (JDK) SE 6 SR12 (64-Bit Version)

The production system uses NTP to synchronize the Hosttime (GMT+1 with Daylight Savings).

The actual bug manifests in two ways:
1) when persisting a record, we set a Date field (datetime in the DB) using TimeService.newDate(). This should give local time and persist the UTC date (local -1 hour). When the bug is triggered, the persisted date looks like the local date (missing the -1 hour)
2) for a business process, we calculate intervalls. I.e. for a given day there may be 24 hour-intervall. 23/25 respectively when we hit winter/summertime. When the bug is triggered, the calculation produces 23 Intervals instead of the expected 24.

It is assumed that the bug is only triggered under heavy load. But 1) the system is reguarly under heavy load (where heavy means that approx. 20 Threads are processing 100k+ transactions) and 2) trying to reproduce the load did not trigger the bug on our local testing/dev environments so far.

The code genrally uses java.util.Date and only the TimeService class utilizes Joda's DateTimeFormatter. I was not able to reproduce the error on the development/testing environment and I'm out of ideas what may cause such an error and how to trigger that.
Do you have any ideas what I could do to further analyze this one?
Feel free to ask any questions (except "why did you do this'n'that). It's a rather old application and will be replaced by a new version soon. But as long as we don't know what causes this bug we can't be sure that this wont happen with the new version (moved completely from to joda).

ParameterString for the JDBC Driver

Portions from the TimeService
11 years ago
no, the ER model doesn't make an assumption about concurrent access on the actual data.
(given that I understood you correctly)
There are JDBC drivers which return the id of an updated row (update/insert/delete, while I'm only sure on the insert).
Otherwise, you could consider a similar approach as discussed in this ( thread.
Create stored procedures that take the parameters for the new/updated row and the UUID of the client requesting the operation, this way, ou have everything in your DB.
Whats wrong with the results from google? I don't have experience with Graphs in Java, but gives enough results for a start, no?
12 years ago
Uhm, okay, I've found this in the Filter API
"A typical implementation of this method would follow the following pattern:-
1. Examine the request
2. Optionally wrap the request object with a custom implementation to filter content or headers for input filtering
3. Optionally wrap the response object with a custom implementation to filter content or headers for output filtering
4. a) Either invoke the next entity in the chain using the FilterChain object (chain.doFilter()),
4. b) or not pass on the request/response pair to the next entity in the filter chain to block the request processing
5. Directly set headers on the response after invocation of the next entity in the filter chain.

4b) looks the answer to my question but I still want to verify this with you
12 years ago

I'm using Spring 2.x and utilize a Spring SecurityFilterChain for authentication.

The chain is defined as follows:
1) spring...CommonsRequestLoggingFilter
- add custom stuff to log messages

2) spring...HttpSessionContextIntegrationFilter
- handling of the SecurityContextHolder

3) custom filter for logouput about authentication state

4) spring...ExceptionTranslationFilter
- handle spring...AuthenticationExceptions, thrown during the following authentication process

5) jespa...SecurityService
- Jespa's ( library for NTLM authentication

6) custom filter to obtain UserDetails from LDAP based on the successful authentication from filter 5

Now, if NTLM authentication fails, the jespa library throws a jespa.SecurityProviderException. This means, that the ExceptionTranslationFilter will not recognize this authentication. The jespa library defines, that when the NTLM authentication fails, it redirects the request to a fallback location (i.e. error page).
This in turn means, that if the NTLM authentication fails, I'll leave the FilterChain with traversing it completely. (additionally, the API contract of the Jespa library does not allow to throw something else then a SecurityProviderException. I've checked with their support. They need this to do internal cleanups if the authentication fails)

My question is: Is this problematic? Does the filterchain always have to be traversed completely? I fear that the chain may be in an inconsistent state and I get unexpected side-effects if the the filter 5 just jumps out of the chain with a redirect. I couldn't find the answer in the docs until now. Could you please clarify this? I'll happily provide additional information if needed.

12 years ago
Sorry, I was unable to fully understand what it is that you want to achieve or what your problem is.

Do you have a Swing table populated with values from a ResultSet?
Do you want to update the Swing-Tables?
Do you want to update the Database records?

Pleasy try again and try to give a more conscious example.
That's more of a JSP question. To be more specific, it's a HTML question.
If you read up on the input-TAG, you'll find the "checked" attribute.

So you'll generate a conditional expression using JSP to create the input tag with a checked attribute according to the value of your object's gender.

The result for the checked button looks like
No, I'll have to do this. But honestly, I can't imagine how this would be possible. All machines to which this application was deployed are business-machines in the same company with a homogenous-setup - this also applies to the user setup.
My application uses DOM-Parsing of XML documents and validates the xml documents via a xsd file. This works on my Development and test machines (Win XP/OSX 10.6) and on most pcs (homogenous XP business pcs) it was deployed to. Now one pc throws a SAXParseException(failed to read schema document). I've verified that the expected file is in the expected location. Please see below for an extract of the code in question and the stack trace. I'm not able to reproduce this behaviour on my machines. Any tips on debugging this or possible root causes appreciated.

Lachlan Hope wrote:
public class myclass1 {
private myobject mo

where 'myobject' is an object of a type defined in a different class.
within this class there are two methods.
The first actually creates the objects:

void method1(){
myobject mo = new myobject();

Then the second needs to update these objects, so:

void method2(){

you have used -- myobject mo = new myobject();
after private myobject mo
so no need of reassigning mo to type myobject
you can directly use mo = new myobject();

Based on this scenario, the second quote misinterprets the problem. It's not that you are reassigning something but he problem is that you never have an non-null-initialized instance variable "mo".
Your method1() just creates a local object (local to method1()) which is discarded after the method is left. You want
"mo = new myobject()" instead of "myobject mo = new myobject()".
13 years ago

J Winton wrote:Is it because the switch wont work with a float and only an int?

Almost correct.

A switch works with the byte, short, char, and int primitive data types. It also works with enumerated types (discussed in Classes and Inheritance) and a few special classes that "wrap" certain primitive types: Character, Byte, Short, and Integer (discussed in Simple Data Objects ).

13 years ago