So interesting, so they developed everything in Java Tx management ???
sounds strange ha !
On Mon, Mar 17, 2008 at 8:28 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> There isn't much active development on it because the project is
> basically done. The project has a narrowly focused, write a
> transaction logging system. The project was complete a few years ago
> and all known bugs have been fixed.
>
> So although there is no active development, this code is used in
> Geronimo TX and some ObjectWeb projects.
>
> -dain
>
>
>
> On Mar 17, 2008, at 1:28 AM, Mohammad Nour El-Din wrote:
>
> > I looked at the HOWL project at ObjectWeb and seems that it is an old
> > project and no further development is made, so why we use it ?
> >
> > On Sun, Mar 16, 2008 at 8:07 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> >> After thinking about this more, I don't think that we should turn on
> >> recovery at this point in the 3.0 release cycle. I think it is good
> >> turning it on in trunk (3.1) so we can get lots of testing in before
> >> releasing it.
> >>
> >> One other thing, the tx logs should be in a directory in the data
> >> directory. I'm not sure if that is happening now but the property
> >> should be something like data/txlog.
> >>
> >> -dain
> >>
> >>
> >>
> >> On Mar 16, 2008, at 10:03 AM, Dain Sundstrom wrote:
> >>
> >>> On Mar 16, 2008, at 9:33 AM, David Jencks wrote:
> >>>
> >>>>
> >>>> On Mar 15, 2008, at 2:37 PM, David Blevins wrote:
> >>>>
> >>>>>
> >>>>> On Mar 15, 2008, at 12:06 AM, David Jencks wrote:
> >>>>>
> >>>>>> While not ideal, I think using a working although slower
> >>>>>> transport is a reasonable compromise to a faster, broken
> >>>>>> transport until we can get a fixed activemq out.
> >>>>>
> >>>>> We definitely need the vm transport for the embedded testing
> >>>>> scenarios and we don't have tx recovery yet, so this is something
> >>>>> we probably don't want enable by default. We can wrap the
> >>>>> wrapping with the "duct tape" flag like so:
> >>>>>
> >>>>> if (System.getProperty("duct tape") != null) {
> >>>>> xaResource = new WrapperNamedXAResource(xaResource,
> >>>>> container.getContainerID().toString());
> >>>>> }
> >>>>> EndpointHandler endpointHandler = new EndpointHandler(container,
> >>>>> deploymentInfo, instanceFactory, xaResource);
> >>>>>
> >>>>> If you have time to make the change and rollback the service-
> >>>>> jar.xml settings, that'd be great, otherwise I'll get to it before
> >>>>> we release.
> >>>>
> >>>> You should probably check my work :-) but after some work I think
> >>>> the current status is:
> >>>>
> >>>> - recovery works if howl log configured in tm configuration
> >>>> - there's a flag TxRecovery for MDB container and the DBCP pools
> >>>> that turns on the NamedXAResource wrapping
> >>>> - recovery and wrapping is turned on for standalone and tomcat, and
> >>>> these use the amq tcp transport
> >>>> - recovery and wrapping is turned off for embedded and it uses vm
> >>>> transport
> >>>>
> >>>> The tests break if you turn on recovery and wrapping in embedded
> >>>> because the howl log locks its log files and does not unlock them.
> >>>> Without a "stop" lifecycle call I don't know how the howl log can
> >>>> determine its time for a clean shutdown.
> >>>
> >>> How about a finalizer (assuming we have a point where the log is
> >>> GCed)? We could subclass the howl log service in OpenEJB and add
> >>> the finalizer.
> >>>
> >>> -dain
> >>
> >>
> >
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
>
>
--
Thanks
- Mohammad Nour
