tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars-Fredrik Smedberg <itsme...@gmail.com>
Subject Re: JDBC Transactions vs EJBs and @TransactionAttribute(...) and more...
Date Fri, 17 Oct 2014 06:31:14 GMT
haha... true true.... will direct it to them

/LF

On Fri, Oct 17, 2014 at 8:22 AM, Romain Manni-Bucau <
rmannibucau@tomitribe.com> wrote:

> purequery questions are for IBMs ;)
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2014-10-17 8:19 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> > @Romain
> >
> > Is there something similar to checkDs that I can do when using EJBs,
> > Container Managed tx and PureQuery (which in turn gets connections from
> an
> > injected datasource and fires queries...). That is checkDs without JPA?
> >
> > Regards
> > LF
> >
> > On Thu, Oct 16, 2014 at 3:48 PM, Lars-Fredrik Smedberg <
> itsmeden@gmail.com>
> > wrote:
> >
> >> True haha... will have a look at it... I really want to learn the
> details
> >> (and in my case have to due to some design we are in the middle of)...
> >>
> >> Anyway... thanks for all help, preciate it!
> >>
> >> /LF
> >>
> >> On Thu, Oct 16, 2014 at 3:42 PM, Romain Manni-Bucau <
> >> rmannibucau@tomitribe.com> wrote:
> >>
> >>> hehe you are curious, read
> >>> org.apache.openjpa.kernel.BrokerImpl#beforeCompletion. It basically
> >>> check all state of the entities
> >>> Romain Manni-Bucau
> >>> Twitter: @rmannibucau
> >>> Blog: http://rmannibucau.wordpress.com/
> >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>> Github: https://github.com/rmannibucau
> >>>
> >>>
> >>>
> >>> 2014-10-16 15:38 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> >>> > Thanks for the answer
> >>> >
> >>> > What exactly is involved in a checkDs1() call?
> >>> >
> >>> > Regards
> >>> > LF
> >>> >
> >>> > On Thu, Oct 16, 2014 at 3:33 PM, Romain Manni-Bucau <
> >>> > rmannibucau@tomitribe.com> wrote:
> >>> >
> >>> >> 2014-10-16 15:01 GMT+02:00 Lars-Fredrik Smedberg <
> itsmeden@gmail.com>:
> >>> >> > Thanks again, see below.
> >>> >> >
> >>> >> > On Thu, Oct 16, 2014 at 2:05 PM, Romain Manni-Bucau <
> >>> >> > rmannibucau@tomitribe.com> wrote:
> >>> >> >
> >>> >> >> 2014-10-16 13:20 GMT+02:00 Lars-Fredrik Smedberg <
> >>> itsmeden@gmail.com>:
> >>> >> >> > Just one more thing I forgot to put in the other
mail
> >>> >> >> >
> >>> >> >> > With "Depend, using ManagedConnection it will be
green but it
> >>> will not
> >>> >> >> do what
> >>> >> >> > you expect." you mean that I will think it runs in
a tx but its
> >>> not
> >>> >> and
> >>> >> >> in
> >>> >> >> > case of failure I might get inconsistency?
> >>> >> >> >
> >>> >> >>
> >>> >> >> right, if datasource2.commit() fails but ds1.commit()
passed then
> >>> you
> >>> >> >> are not consistent. Of course with jpa it is not that
impacting
> >>> since
> >>> >> >>
> >>> >> >
> >>> >> > Could you please explain how jpa tries to solve this? I guess
it
> >>> will not
> >>> >> > completely remove the consisitency risk but only lower the
risk?
> >>> >> >
> >>> >>
> >>> >> It doesn't but it limits it in practise. It basically do a check
> >>> >> before calling commit. All checks pass before commit:
> >>> >>
> >>> >> checkDs1();
> >>> >> checkDs2();
> >>> >> commitDs1();
> >>> >> commitDs2();
> >>> >>
> >>> >> so it avoids half of the ds2 commit fails but not ds1.
> >>> >>
> >>> >> >
> >>> >> >> the provider checks it before committing.
> >>> >> >>
> >>> >> >>
> >>> >> > So I guess in our case: non xa datasources with multiple
> connections
> >>> >> within
> >>> >> > a transaction we are not guaranteed consistency?
> >>> >> >
> >>> >>
> >>> >> Yep
> >>> >>
> >>> >> > I see also that some db vendors (MQ SQL) has some optimization
so
> >>> >> > transactions involving multiple connections from different
> >>> datasources
> >>> >> but
> >>> >> > from the same db is not promoted to a distributed tx
> >>> >> >
> >>> >> > => Is that only vendor specific or is that according to
spec to
> not
> >>> >> promote
> >>> >> > it in certain situations?
> >>> >> >
> >>> >>
> >>> >> vendor
> >>> >>
> >>> >> >
> >>> >> > resource = datasource != underlying db (without using openejb
> >>> >> >> aliases). Each datasource has its own pool of connection
and then
> >>> its
> >>> >> >> own JTA integration (different Xid).
> >>> >> >>
> >>> >> >> > Regards
> >>> >> >> > LF
> >>> >> >> >
> >>> >> >> > On Thu, Oct 16, 2014 at 12:59 PM, Romain Manni-Bucau
<
> >>> >> >> > rmannibucau@tomitribe.com> wrote:
> >>> >> >> >
> >>> >> >> >> Well I don't know websphere enough to answer
to the related
> >>> question
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >> 2014-10-16 12:55 GMT+02:00 Lars-Fredrik Smedberg
<
> >>> itsmeden@gmail.com
> >>> >> >:
> >>> >> >> >> > Thanks Romain, please see if you can help
me on the follow
> up
> >>> >> below?
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> > On Thu, Oct 16, 2014 at 9:33 AM, Romain
Manni-Bucau <
> >>> >> >> >> rmannibucau@gmail.com>
> >>> >> >> >> > wrote:
> >>> >> >> >> >
> >>> >> >> >> >> 2014-10-16 9:31 GMT+02:00 Lars-Fredrik
Smedberg <
> >>> >> itsmeden@gmail.com
> >>> >> >> >:
> >>> >> >> >> >> > @Romain
> >>> >> >> >> >> >
> >>> >> >> >> >> > I can see in the ManagedConnection
code that the reused
> >>> >> Connection
> >>> >> >> is
> >>> >> >> >> per
> >>> >> >> >> >> > Transaction per DataSource.
> >>> >> >> >> >> >
> >>> >> >> >> >> > So if I use 2 x DataSource (pointing
to the same DB but
> with
> >>> >> >> different
> >>> >> >> >> >> > properties set) I will within a
transaction use 2
> >>> connections,
> >>> >> >> >> correct?
> >>> >> >> >> >> >
> >>> >> >> >> >> yep
> >>> >> >> >> >>
> >>> >> >> >> >> > Will this result in a distributed
transaction?
> >>> >> >> >> >> >
> >>> >> >> >> >>
> >>> >> >> >> >> No, this ManagedConnection is to get
JTA integration
> "locally"
> >>> >> (ie we
> >>> >> >> >> >> integrate locally with XA hooks but
it is not distributed).
> >>> For
> >>> >> that
> >>> >> >> >> >> you have to use a really XA datasource.
> >>> >> >> >> >>
> >>> >> >> >> >
> >>> >> >> >> > We use WebSphere in test/production and
the driver included
> in
> >>> >> >> >> db2jcc4.jar.
> >>> >> >> >> >
> >>> >> >> >> > As far as I understand from the documentation
if the type
> >>> >> attribute of
> >>> >> >> >> the
> >>> >> >> >> > datasource element in the configuration
is not set it will
> >>> search
> >>> >> the
> >>> >> >> >> > driver jar for datasources in the following
order:
> >>> >> >> >> >
> >>> >> >> >> > javax.sql.ConnectionPoolDataSource
> >>> >> >> >> > javax.sql.DataSource
> >>> >> >> >> > javax.sql.XADataSource
> >>> >> >> >> >
> >>> >> >> >> > In our testconfiguration we do not specify
the type
> attribute
> >>> so I
> >>> >> >> assume
> >>> >> >> >> > we are NOT using XA datasource. correct?
> >>> >> >> >> >
> >>> >> >> >> > So some questions on the above:
> >>> >> >> >> >
> >>> >> >> >> > 1. In what cases will I not need a distributed
tx?
> >>> >> >> >>
> >>> >> >> >> You don't need it either when you have a single
or totally
> >>> >> decorelated
> >>> >> >> >> resources (datasource for instane) or when you
want
> performances
> >>> (XA
> >>> >> >> >> is slow) and can accept some manual operations
to fix
> >>> inconsistency
> >>> >> if
> >>> >> >> >> it happens (should be rare)
> >>> >> >> >>
> >>> >> >> >> > a) A tx with 1 connection to a DB? No!
> >>> >> >> >> > b) A tx with 2 connections (from seperate
datasources)
> >>> connected to
> >>> >> >> the
> >>> >> >> >> > same DB? <== ??
> >>> >> >> >> > c) A tx with 2 connections (from seperate
datasources)
> >>> connected to
> >>> >> >> >> > different DBs? Yes!
> >>> >> >> >> > d) A tx with 1 connection to a DB and e.g.
JMS? Yes!
> >>> >> >> >> >
> >>> >> >> >> > 2. If I have a scenario that requires a
distributed and the
> >>> >> datasource
> >>> >> >> >> that
> >>> >> >> >> > is used is NOT an XA datasource what will
happen? Exception?
> >>> >> >> >> >
> >>> >> >> >>
> >>> >> >> >> Depend, using ManagedConnection it will be green
but it will
> not
> >>> do
> >>> >> >> >> what you expect.
> >>> >> >> >>
> >>> >> >> >> > Thanks
> >>> >> >> >> >
> >>> >> >> >> > Regards
> >>> >> >> >> > Lars-Fredrik
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> >>
> >>> >> >> >> >> > Regards
> >>> >> >> >> >> > LF
> >>> >> >> >> >> >
> >>> >> >> >> >> > On Wed, Oct 15, 2014 at 8:48 AM,
Romain Manni-Bucau <
> >>> >> >> >> >> rmannibucau@gmail.com>
> >>> >> >> >> >> > wrote:
> >>> >> >> >> >> >
> >>> >> >> >> >> >> Hi
> >>> >> >> >> >> >>
> >>> >> >> >> >> >> that's the global idea yes
> >>> >> >> >> >> >>
> >>> >> >> >> >> >> about transaction manager:
> >>> >> >> >> >> >>
> >>> >> >> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >>
> >>> >> >>
> >>> >>
> >>>
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.geronimo.components/geronimo-transaction/3.1.1/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java#TransactionManagerImpl
> >>> >> >> >> >> >> is th eone
> >>> >> >> >> >> >>
> >>> >> >> >> >> >> idea is simple: invoke registered
hooks when needed and
> >>> just
> >>> >> >> manage
> >>> >> >> >> >> >> the lifecycle then EJB containers
start/stop these hooks
> >>> >> calling
> >>> >> >> the
> >>> >> >> >> >> >> tx mgr (look SingletonContainer
hierarchy in
> openejb-core
> >>> for
> >>> >> >> >> >> >> instance)
> >>> >> >> >> >> >>
> >>> >> >> >> >> >>
> >>> >> >> >> >> >> Romain Manni-Bucau
> >>> >> >> >> >> >> @rmannibucau
> >>> >> >> >> >> >> http://www.tomitribe.com
> >>> >> >> >> >> >> http://rmannibucau.wordpress.com
> >>> >> >> >> >> >> https://github.com/rmannibucau
> >>> >> >> >> >> >>
> >>> >> >> >> >> >>
> >>> >> >> >> >> >> 2014-10-15 1:19 GMT+02:00 Lars-Fredrik
Smedberg <
> >>> >> >> itsmeden@gmail.com
> >>> >> >> >> >:
> >>> >> >> >> >> >> > Hi Romain
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > Thanks for the link to
the ManagedConnection, some
> >>> questions
> >>> >> on
> >>> >> >> it
> >>> >> >> >> >> (so I
> >>> >> >> >> >> >> > understand it correctly)
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > - The connection is bound
to the tx when the first
> >>> method is
> >>> >> >> >> called on
> >>> >> >> >> >> >> the
> >>> >> >> >> >> >> > connect (except for toString,
equals and hashcode),
> and
> >>> if
> >>> >> its
> >>> >> >> not
> >>> >> >> >> >> >> already
> >>> >> >> >> >> >> > bound, correct?
> >>> >> >> >> >> >> > - Do I understand correctly
that I will always use
> (using
> >>> >> >> >> delegation
> >>> >> >> >> >> in
> >>> >> >> >> >> >> the
> >>> >> >> >> >> >> > proxy) the same connection
(the one bound to the tx)
> >>> >> regardless
> >>> >> >> of
> >>> >> >> >> if
> >>> >> >> >> >> I
> >>> >> >> >> >> >> use
> >>> >> >> >> >> >> > getConnection()/close()
multiple times within an EJB
> that
> >>> >> >> handles
> >>> >> >> >> tx?
> >>> >> >> >> >> >> > - In the above case the
connection I think I'm using
> >>> (when I
> >>> >> >> simple
> >>> >> >> >> >> look
> >>> >> >> >> >> >> at
> >>> >> >> >> >> >> > the code) is returned
to the pool and the bound one is
> >>> used?
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > Where can I get more understanding
of the
> >>> TransactionManager
> >>> >> and
> >>> >> >> >> its
> >>> >> >> >> >> >> > relation to the transactions
annotated in the EJB?
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > Very nice to take a look
at the code, really makes the
> >>> >> >> >> understanding
> >>> >> >> >> >> alot
> >>> >> >> >> >> >> > easier, thanks!
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > /LF
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > On Wed, Oct 15, 2014 at
1:03 AM, Romain Manni-Bucau <
> >>> >> >> >> >> >> rmannibucau@gmail.com>
> >>> >> >> >> >> >> > wrote:
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> >> Hi
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >> this is actually more
bound to JTA (you can read
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >>
> >>> >> >>
> >>> >>
> >>>
> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/resource/jdbc/managed/local/ManagedConnection.java
> >>> >> >> >> >> >> >> )
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >> 2014-10-15 0:14 GMT+02:00
Lars-Fredrik Smedberg <
> >>> >> >> >> itsmeden@gmail.com
> >>> >> >> >> >> >:
> >>> >> >> >> >> >> >> > Hi
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > Using JDBC, creating
a connection and setting it to
> >>> auto
> >>> >> >> commit
> >>> >> >> >> >> false
> >>> >> >> >> >> >> to
> >>> >> >> >> >> >> >> be
> >>> >> >> >> >> >> >> > able to group
more than one statement into a single
> >>> >> >> transaction
> >>> >> >> >> I
> >>> >> >> >> >> >> >> > understand.
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > - Is it possible
to compare that to an EJB with a
> >>> >> >> >> >> >> @TransactionAttribute
> >>> >> >> >> >> >> >> > set? I would
like to understand more in detail how
> >>> the EJB
> >>> >> >> >> handles
> >>> >> >> >> >> >> >> > transactions,
datasources and connections "under
> the
> >>> >> hood".
> >>> >> >> >> >> >> >> > (it all comes
from a discussion with a DBA)
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > If I use @Resource
to inject a Datasource and use
> to
> >>> >> >> retrieve a
> >>> >> >> >> >> >> >> connection
> >>> >> >> >> >> >> >> > I usually call
close on it after I done using it,
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > - Will close
on the connection actually close it
> or is
> >>> >> that
> >>> >> >> >> done at
> >>> >> >> >> >> >> the
> >>> >> >> >> >> >> >> > commit of the
transaction (assume we are in an EJB
> >>> with
> >>> >> >> >> >> >> >> > @TransactionAttribute
set)?
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >> will be done later
to support rollback
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >> > - Will the container
automatically set auto commit
> >>> false
> >>> >> to
> >>> >> >> any
> >>> >> >> >> >> >> >> connections
> >>> >> >> >> >> >> >> > retrieved within
the transaction?
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >> all JTA ones, can
also depend on JPA provider config
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >> > - ... and many
more questions :)
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > Maybe I'm mixing
the topics a bit but it would be
> >>> really
> >>> >> >> great
> >>> >> >> >> to
> >>> >> >> >> >> >> >> > understand it
all more in-depth to be able to have
> the
> >>> >> >> >> >> understanding
> >>> >> >> >> >> >> and
> >>> >> >> >> >> >> >> > discuss it with
the DBA.
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > Thanks
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > --
> >>> >> >> >> >> >> >> > Med vänlig hälsning
/ Best regards
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > Lars-Fredrik
Smedberg
> >>> >> >> >> >> >> >> >
> >>> >> >> >> >> >> >> > STATEMENT OF
CONFIDENTIALITY:
> >>> >> >> >> >> >> >> > The information
contained in this electronic
> message
> >>> and
> >>> >> any
> >>> >> >> >> >> >> >> > attachments to
this message are intended for the
> >>> exclusive
> >>> >> >> use
> >>> >> >> >> of
> >>> >> >> >> >> the
> >>> >> >> >> >> >> >> > address(es) and
may contain confidential or
> privileged
> >>> >> >> >> >> information. If
> >>> >> >> >> >> >> >> > you are not the
intended recipient, please notify
> >>> >> >> Lars-Fredrik
> >>> >> >> >> >> >> Smedberg
> >>> >> >> >> >> >> >> > immediately at
itsmeden@gmail.com, and destroy all
> >>> >> copies of
> >>> >> >> >> this
> >>> >> >> >> >> >> >> > message and any
attachments.
> >>> >> >> >> >> >> >>
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > --
> >>> >> >> >> >> >> > Med vänlig hälsning
/ Best regards
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > Lars-Fredrik Smedberg
> >>> >> >> >> >> >> >
> >>> >> >> >> >> >> > STATEMENT OF CONFIDENTIALITY:
> >>> >> >> >> >> >> > The information contained
in this electronic message
> and
> >>> any
> >>> >> >> >> >> >> > attachments to this message
are intended for the
> >>> exclusive
> >>> >> use
> >>> >> >> of
> >>> >> >> >> the
> >>> >> >> >> >> >> > address(es) and may contain
confidential or privileged
> >>> >> >> >> information. If
> >>> >> >> >> >> >> > you are not the intended
recipient, please notify
> >>> >> Lars-Fredrik
> >>> >> >> >> >> Smedberg
> >>> >> >> >> >> >> > immediately at itsmeden@gmail.com,
and destroy all
> >>> copies of
> >>> >> >> this
> >>> >> >> >> >> >> > message and any attachments.
> >>> >> >> >> >> >>
> >>> >> >> >> >> >
> >>> >> >> >> >> >
> >>> >> >> >> >> >
> >>> >> >> >> >> > --
> >>> >> >> >> >> > Med vänlig hälsning / Best regards
> >>> >> >> >> >> >
> >>> >> >> >> >> > Lars-Fredrik Smedberg
> >>> >> >> >> >> >
> >>> >> >> >> >> > STATEMENT OF CONFIDENTIALITY:
> >>> >> >> >> >> > The information contained in this
electronic message and
> any
> >>> >> >> >> >> > attachments to this message are
intended for the
> exclusive
> >>> use
> >>> >> of
> >>> >> >> the
> >>> >> >> >> >> > address(es) and may contain confidential
or privileged
> >>> >> >> information. If
> >>> >> >> >> >> > you are not the intended recipient,
please notify
> >>> Lars-Fredrik
> >>> >> >> >> Smedberg
> >>> >> >> >> >> > immediately at itsmeden@gmail.com,
and destroy all
> copies
> >>> of
> >>> >> this
> >>> >> >> >> >> > message and any attachments.
> >>> >> >> >> >>
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> > --
> >>> >> >> >> > Med vänlig hälsning / Best regards
> >>> >> >> >> >
> >>> >> >> >> > Lars-Fredrik Smedberg
> >>> >> >> >> >
> >>> >> >> >> > STATEMENT OF CONFIDENTIALITY:
> >>> >> >> >> > The information contained in this electronic
message and any
> >>> >> >> >> > attachments to this message are intended
for the exclusive
> use
> >>> of
> >>> >> the
> >>> >> >> >> > address(es) and may contain confidential
or privileged
> >>> >> information. If
> >>> >> >> >> > you are not the intended recipient, please
notify
> Lars-Fredrik
> >>> >> >> Smedberg
> >>> >> >> >> > immediately at itsmeden@gmail.com, and destroy
all copies
> of
> >>> this
> >>> >> >> >> > message and any attachments.
> >>> >> >> >>
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > --
> >>> >> >> > Med vänlig hälsning / Best regards
> >>> >> >> >
> >>> >> >> > Lars-Fredrik Smedberg
> >>> >> >> >
> >>> >> >> > STATEMENT OF CONFIDENTIALITY:
> >>> >> >> > The information contained in this electronic message
and any
> >>> >> >> > attachments to this message are intended for the
exclusive use
> of
> >>> the
> >>> >> >> > address(es) and may contain confidential or privileged
> >>> information. If
> >>> >> >> > you are not the intended recipient, please notify
Lars-Fredrik
> >>> >> Smedberg
> >>> >> >> > immediately at itsmeden@gmail.com, and destroy all
copies of
> this
> >>> >> >> > message and any attachments.
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > Med vänlig hälsning / Best regards
> >>> >> >
> >>> >> > Lars-Fredrik Smedberg
> >>> >> >
> >>> >> > STATEMENT OF CONFIDENTIALITY:
> >>> >> > The information contained in this electronic message and any
> >>> >> > attachments to this message are intended for the exclusive
use of
> the
> >>> >> > address(es) and may contain confidential or privileged
> information.
> >>> If
> >>> >> > you are not the intended recipient, please notify Lars-Fredrik
> >>> Smedberg
> >>> >> > immediately at itsmeden@gmail.com, and destroy all copies
of this
> >>> >> > message and any attachments.
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Med vänlig hälsning / Best regards
> >>> >
> >>> > Lars-Fredrik Smedberg
> >>> >
> >>> > STATEMENT OF CONFIDENTIALITY:
> >>> > The information contained in this electronic message and any
> >>> > attachments to this message are intended for the exclusive use of the
> >>> > address(es) and may contain confidential or privileged information.
> If
> >>> > you are not the intended recipient, please notify Lars-Fredrik
> Smedberg
> >>> > immediately at itsmeden@gmail.com, and destroy all copies of this
> >>> > message and any attachments.
> >>>
> >>
> >>
> >>
> >> --
> >> Med vänlig hälsning / Best regards
> >>
> >> Lars-Fredrik Smedberg
> >>
> >> STATEMENT OF CONFIDENTIALITY:
> >> The information contained in this electronic message and any
> >> attachments to this message are intended for the exclusive use of the
> >> address(es) and may contain confidential or privileged information. If
> >> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> >> immediately at itsmeden@gmail.com, and destroy all copies of this
> >> message and any attachments.
> >>
> >
> >
> >
> > --
> > Med vänlig hälsning / Best regards
> >
> > Lars-Fredrik Smedberg
> >
> > STATEMENT OF CONFIDENTIALITY:
> > The information contained in this electronic message and any
> > attachments to this message are intended for the exclusive use of the
> > address(es) and may contain confidential or privileged information. If
> > you are not the intended recipient, please notify Lars-Fredrik Smedberg
> > immediately at itsmeden@gmail.com, and destroy all copies of this
> > message and any attachments.
>



-- 
Med vänlig hälsning / Best regards

Lars-Fredrik Smedberg

STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsmeden@gmail.com, and destroy all copies of this
message and any attachments.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message