I talked with DJencks yesterday on IRC and he explained the history of
of both HOWL, JOTM and G Tx manager and Connector system. I didn't ask
to change, all what I wanted to know is that, if JOTM was written even
before G so why we didn't use it, that's all :). Thanks anyway for
both of you and DJencks :).
On Wed, Mar 19, 2008 at 4:12 AM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Due to the way the specs are written the Connector system is really
> married to the transaction manager, so if you take one you have to
> take the other. I like the G connector system and don't want to learn
> another one, so I see no reason to switch.
>
> -dain
>
>
>
> On Mar 18, 2008, at 7:56 AM, Mohammad Nour El-Din wrote:
>
> > One more question, if ObjectWeb's JOTM is using HOWL and it is a Tx
> > manager, so why Geronimo is uing it's own Tx manager ?
> >
> > On Tue, Mar 18, 2008 at 11:45 AM, Mohammad Nour El-Din
> > <[EMAIL PROTECTED]> wrote:
> >> 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
> >>
> >
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
>
>
--
Thanks
- Mohammad Nour
