Hello, Perhaps I'm not reading this properly, but it doesn't seem like you need or or want a singleton, because you don't want a single instance, and associated data, accessible from all requests. While you could use a singleton, and manage the separation of requests/transactions manually, I'm not sure you want all of that overhead. If I understand what you are trying to do is: on a per-request basis, store your audit events in-memory as you are progressing through the transaction. When the transaction is committed, to perhaps add more audit information (ie was it successful or rolled back) and eventually commit those audit events to your data store. If this is true, I think you might have a quite a few options:
Option 1: Wrap the ORM classes you're using. If you're using JPA, for example, you can extend from your EntityManager/EntityTransaction classes and using that those classes to store and manipulate your audit information. Such that when you say em.getTransaction().begin() it instantiates a simple ArrayList<AuditEvent> within the em instance and provides a place for you to add those events to. When you say em.getTransaction().commit(), your wrapper class can call commit() on the superclass and add any audit events that may be necessary. Before returning the results of the commit back, your wrapper class can persist the audit events. Option 2: Create a POJO class to store your audit events. In this case, I might write a ServletRequestListener to instantiate the POJO class (lets call AuditManager) and store it in the request context for use on requestInitalized(). Then, at the end of the request (requestDestroyed()), persist the audit events. The problem with this is that you're relying on the requestDestroyed() to be called - which it normally would be but could not be if for some reason the request doesn't complete normally (runtime error, server shits the bed, etc). Option 3: Use a stateful EJB. You can use dependency injection to access your EJB and have it store your session-specific audit events, then call the persist() (or whatever) method when you feel you are ready for the events to be persisted. There are several more options you have, which if none of these are adequate I can try to explain. However, I want to make sure that I'm interpreting your request properly first =). Regards, Steve On Mar 25, 10:14 pm, scphantm <[email protected]> wrote: > I am working on a design to revamp a system that i wrote about 8 years > ago when i learned Java because the outsource crew we originally hired > to write it pissed me off for the last time. Im having a problem in > the design that im sure is easy to fix but the fix eludes me. > > Its a middleware application. basically its an HTTP servlet that > accepts an XML document from a client and process it. its deployed as > a war file on jboss 5.1 > > Now, when the system gets a transaction, the first thing it does is go > to a router that pulls the beginning tag out of the xml to figure out > what the transaction is and routes it to the appropriate manager. > now, currently the first thing that happens when it reaches the > manager is its written to the database, then as the transaction > progresses that record is updated. you can see the core of my problem > already and the main reason im redesigning it. but i have an > interesting problem. each transaction creates several audit log > entries, those logs are linked to the original record by ID. but if i > havn't written the original transaction yet, i have no ID to link the > audits to. > > SO, basically what i need is a transaction level session space for > lack of a better term for it something that is created when the > transaction starts that i can simply insert my audit objects into > during the transaction and when the transaction is finished, i pass to > a method that writes the transaction data and then goes to that > session info and writes the audit log entries. i was looking at JTA > to do this but i think thats a bit overkill for my needs. i was > thinking about doing this as a simple singleton but im not sure if > that singleton would cross transactions, which would be very bad. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
